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^ At the Garmisch Conference, A. Perlis prophetically observed: Almost all users re- 
quire mueh less from a large operating system than is provided. 
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® This is not to say that I advocate the other extreme, vividly described at the 
Garmisch Conference by R. M. Graham: We build systems like the Wright broth- 
ers built airplanes - build the whole thing, push it off the cliff, let it crash, and start 
over again. 
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^ For the vast majority of software engineers, the perennial question of whether {un- 
defined = undefined’) = true or {undefined = undefined’) = false is of precious little 
signihcance and even less consequence. There, what matters is that undefined should 
never be encountered and — if it happens — should raise all sorts of alarms. The 
same, of course, goes for similar concerns with other errors of design: while they 
could be viewed as a fertile ground for subtle considerations, in the bread-earning 
community the need to avoid them is dominant, and the guarantee that errors, if 
made, will not remain undetected is a prime concern. 
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® It is large systems that are encountering great difficulties. We should not expect the 
production of such systems to be easy. — K. Kolence at the Garmisch Conference 
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“ cf. K. Samelson at the Garmisch Conference: far the majority of problems raised 

here are quite unspecific to software engineering, but are simply management prob- 
lems. ... Perhaps programmers should learn management before undertaking large 
scale jobs. 

^ In a hard to describe way it is indeed the organisation, as distinct from individuals it 
employs, that gains the relevant experience. Of course, the employees, each in her/his 
special way, also gain experience from the completed tasks, but there seems to be 
a clear synergy effect, making the combined gain larger than the sum of individual 



ones. 
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I am using the expression “time-like” in order to avoid any suspicion that what is 
implied is the well-behaved, uniform time of classical physics and theology. 
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On closer scrutiny, the apparently insurmountable implementational difficulties of 
this approach turn out much less forbidding. 
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Memex Is Not Enough 



Richard Mark Soley 

Object Management Group, Inc. 
Needham, Massachusetts 



Turning his thinking finally from the application of science to military needs, 
in 1946 the great scientist and research organizer Dr. Vannevar Bush of the 
United States’ wartime Office of Scientific Research and Development wrote a 
seminal paper entitled As We May Think. In it, he challenged us to discover 
ways to encode, link and in general make more accessible the huge store of 
human knowledge developed to that date. 

In the last decade, the emergence of the World Wide Web has been held 
up as the embodiment of that half-century-old vision. While this is a reasonable 
claim, even if true it is simply not enough. Human beings, and more importantly 
our silicon-based information processors, do not simply encode, store and index 
static data; they create new data every nanosecond. Links between static data, 
stale the moment they are created, are simply not enough; the real challenge is 
to link the information processing power we have directly. 

At the core of this effort must be sufficient consensus for interfaces not only 
to store and link data, but to forward and link computational power. This effort 
has informally been underway for decades, with thousands of “stovepiped” sys- 
tem thrown together without any planning. We must renew our efforts to agree 
standards for linking information assets, for mundane (but economically critical) 
“business to consumer” as well as “business to business” supply /service-chain 
integration, and for more interesting problems as well. 

Typically such standardization efforts have centered on the lowest levels of 
the interoperability protocol stack, including the physical cable or the byte- 
transfer level. Even newer approaches based on document type extensions (e.g., 
XML) have focussed only on data movement. Unfortunately, it is the much 
more difficult piece of the puzzle that is required for true processing power 
synchronization: transactional, persistent, secure application interfaces (at the 
lower level) and market-specific interface definitions (at the higher level) are 
absolutely critical. 

Memex — the availability of linked, indexed data — is a great starting point for 
integrating the sum total of human knowledge, as Bush saw a half century ago. 
By simply implementing this vision we abandon it; instead we should focus on 
providing true application-level integration across worldwide networks so that 
knowledge may be shared the moment it is discovered. 
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Abstract. We discuss the possibility of a complete system development 
scheme, supported by semantically rigorous automated tools, within 
which one can go from an extremely high-level, user-friendly requirement 
capture method, which we call play-in scenarios, to a final implemen- 
tation. A cyclic process consisting of verification against requirements 
and synthesis from requirements plays an important part in the scheme, 
which is not quite as imaginary as it may sound. 
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^ Of course, there are many other possible choices for a language to specify behavior, 
including such visual languages as Petri nets [29] or SDL diagrams [33], and more 
algebraic ones like CCS [24] and CSP [19]. 

2 This would be like saying that when you build a car all you need are the structural 
things — body, chassis, wheels, etc. — and an engine, and you then merely stick the 
engine under the hood and you are done. . . 
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® The UML has several means for specifying more elaborate aspects of the struc- 
ture and architecture of the system under development (for example, packages and 
components), but we shall not get into these here. Our emphasis is on classical 
object-oriented structure and full behavior. 

^ See also [11] for a more detailed discussion of various kinds of model execution that 
one might desire. 
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® We mention tasks and processes here, since although we couch much of our discussion 
in the terminology of object-orientation and the UML, there is nothing special to 
objects in what we are discussing. 
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® You can’t simply prepare j 


a collection of 1000 scenarios 


and call that your system. 



How would it operate? What would it do under general dynamic circumstances? 
How are these scenarios related? What happens if things occur that simply do not 
fall under any of the scenarios? And on and on. 

^ Rhapsody actually executes its Base-UML models by generating code from them 
and running the code in a way that is linked to the visual model. 
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Usually, however, there is a minimal, often implicit, requirement that there should 
be at least one run of the system that winds its way correctly through any specificed 
sequence chart. 
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® Requirements could equally well have been specihed using some powerful form of 
temporal logic with path quantifiers; see, e.g., [22, 23] or certain kinds of timing 
diagrams [32]. 
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Abstract. This paper discusses highly general mechanisms for specifying the 
refinement of a real-time system as a collection of lower level parallel 
components that preserve the timing and functional requirements of the upper 
level specification. These mechanisms are discussed in the context of 
ASTRAL, which is a formal specification language for real-time systems. 
Refinement is accomplished by mapping all of the elements of an upper level 
specification into lower level elements that may be split among several parallel 
components. In addition, actions that can occur in the upper level are mapped 
to actions of components operating at the lower level. This allows several 
types of implementation strategies to be specified in a fairly natural way, while 
the price for generality (in terms of complexity) is paid only when necessary. 
The refinement mechanisms are illustrated using a simple digital circuit and a 
much more complex example is sketched. 



1 Introduction 

Refinement is a fundamental design technique that has often challenged the „formal 
methods" community. In most cases, mathematical elegance and proof manageahility 
have exhibited a deep trade-off with the flexibility and freedom that are often needed 
in practice to deal with unexpected or critical situations. A typical example is 
provided by algebraic approaches that exploit some notion of homomorphism between 
algebraic structures. When applied to parallel systems, such approaches led to the 
notion of observational equivalence of processes [8] (i.e. the ability of the lower level 
process to exhibit all and only the observable behaviors of the upper level one). 
Observational equivalence, however, has been proved too restrictive to deal with 
general cases and more flexible notions of inter-level relations have been advocated 

[5]. 

The issue of refinement becomes even more critical when dealing with real-time 
systems where time analysis is a crucial factor. In this case, the literature exhibits only 
a few, fairly limited proposals. [3] is the origin of the present proposal. [6] addresses 
the issue within the context of timed Petri nets and the TRIO language. In this 
approach, a system is modeled as a timed Petri net and its properties are described as 
TRIO formulas. Then, mechanisms are given that refine the original net into a more 
detailed one that preserves the original properties. The approach is limited, however, 
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by the expressive power of pure Petri nets, which do not allow one to deal with 
functional data dependencies. In [11], a system is modeled by an extension of finite 
state machines and its properties are expressed in a real-time logic language. 
Refinement follows a fairly typical algebraic approach by mapping upper level entities 
into lower level ones and pursuing observational equivalence between the two layers. 
In this case, observable variables (i.e. variables that are in the process interface), must 
be identical in the two levels. This leads to a lack of flexibility, as pointed out above, 
that is even more evident in time dependent systems where refined layers must also 
guarantee consistency between the occurrence times of the events. 

In this paper, we propose highly general refinement mechanisms that allow several 
types of implementation strategies to be specified in a fairly natural way. In 
particular, processes can be implemented both sequentially, by refining a single 
complex transition as a sequence or selection of more elementary transitions, and in a 
parallel way, by mapping one process into several concurrent ones. This allows one to 
increase the amount of parallelism through refinement whenever needed or wished. 

Also, asynchronous implementation policies are allowed in which lower level 
actions can have durations unrelated to upper level ones, provided that their effects are 
made visible in the lower level exactly at the times specified by the upper level. For 
instance, in a phone system, many calls must be served simultaneously, possibly by 
exploiting concurrent service by many processors. Such services, however, are 
asynchronous since calls occur in an unpredictable fashion at any instant. Therefore, 
it is not easy to describe a call service that manages a set of calls within a given time 
interval in an abstract way that can be naturally refined as a collection of many 
independent and individual services of single calls, possibly even allowing a dynamic 
allocation of servers to the phones issuing the calls. In Section 8, we outline how this 
goal can be achieved by applying the mechanisms described in this paper. 

Not surprisingly, generality has a price in terms of complexity. In our approach, 
however, this price is paid only when necessary. Simple implementation policies yield 
simple specifications, whereas complex specifications are needed only for 
sophisticated implementation policies. The same holds for the proof system, which is 
built hand-in-hand with the implementation mechanisms. 

Furthermore, the proof system is amenable both for traditional hand-proofs, based 
on human ingenuity and only partially formalized, and for fully formalized, tool- 
supported proofs. Finally, although experience with the application of the proposed 
mechanisms is still limited, it is not difficult to extract from meaningful examples 
suitable guidelines for their systematic application to many real cases. 

This work is presented in the context of ASTRAL, which is a formal specification 
language for real-time systems with the following distinguishing features: 

• It is rooted in both ASLAN [1], which is an untimed state machine formalism, and 
TRIO [7], which is a real-time temporal logic, yielding a new, logic-based, 
process-oriented specification language. 

• It has composable modularization mechanisms that allow a complex system to be 
built as a collection of interacting processes. It also has refinement mechanisms 
to construct a process as a sequence of layers, where each layer is the 
implementation of the layer above. 

• It has a proof obligation system that allows one to formally prove properties of 
interest as consequences of process specifications. This proof system is 
incremental since complex proofs of complex systems can be built by composing 
small proofs that can be carried out, for the most part, independently of each 
other, astral’s proofs are of two types. Intra-level proofs guarantee system 
properties on the basis of local properties that only refer to a single process type. 
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Inter-level proofs guarantee that layer i-tl is a correct implementation of layer i 
without the need to redo intra-level proofs from scratch. 

In this paper, we resume the issue of ASTRAL layering mechanisms and the inter- 
level proofs, which were addressed in a preliminary and fairly restrictive way in [3]. 

This paper is structured as follows. Section 2 provides the necessary background 
on the ASTRAL language. Section 3 summarizes previous purely sequential 
refinement mechanisms. Section 4 motivates the need for their extensions through a 
simple running example and illustrates the essentials of the generalized and parallel 
refinement mechanisms. Section 5 shows their application to the running example. 
Section 6 presents the proof obligations needed to guarantee implementation 
correctness and section 7 applies them to the running example. Section 8 briefly 
summarizes a more complex example. Finally, section 9 provides some concluding 
remarks. For the sake of conciseness in this paper, we concentrate only on the 
essentials. Complete technical details can be found in [9]. 

2 ASTRAL Overview 

An ASTRAL system specification is comprised of a single global specification and a 
collection of state machine specifications. Each state machine specification represents 
a process type of which there may be multiple, statically generated, instances. The 
global specification contains declarations for the process types that comprise the 
system, types and constants that are shared among more than one process type, and 
assumptions about the global environment and critical requirements for the whole 
system. 

An ASTRAL process specification consists of a sequence of levels. Each level is 
an abstract data type view of the process being specified. The first („top level“) view 
is a very abstract model of what constitutes the process (types, constants, variables), 
what the process does (state transitions), and the critical requirements the process must 
meet (invariants and schedules). Lower levels are increasingly more detailed with the 
lowest level corresponding closely to high level code. 

The process being specified is thought of as being in various states, where one 
state is differentiated from another by the values of the state variables, which can be 
changed only by means of state transitions. Transitions are specified in terms of entry 
and exit assertions, where entry assertions describe the constraints that state variables 
must satisfy in order for the transition to fire, and exit assertions describe the 
constraints that are fulfilled by state variables after the transition has fired. An explicit 
non-null duration is associated with each transition. Transitions are executed as soon 
as they are enabled if no other transition is executing in that process. 

Every process can export both state variables and transitions. Exported variables 
are readable by other processes while exported transitions are callable from the 
external environment. Inter-process communication is accomplished by inquiring 
about the values of exported variables and the start and end times of exported 
transitions. 

In addition to specifying system state (through process variables and constants) 
and system evolution (through transitions), an ASTRAL specification also defines 
system critical requirements and assumptions about the behavior of the environment 
that interacts with the system. Assumptions about the behavior of the environment are 
expressed by means of environment clauses that describe the pattern of calls to 
external transitions, which are the stimuli to which the system reacts. Critical 
requirements are expressed by means of invariants and schedules. Invariants 
represent requirements that must hold in every state reachable from the initial state, no 
matter what the behavior of the external environment is, while schedules represent 
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additional properties that must be satisfied provided that the external environment 
behaves as assumed. 

Invariants and schedules are proved over all possible executions of a system. A 
system execution is a set of process executions that contains one process execution for 
each process instance in the system. A process execution for a given process instance 
is a history of events on that instance. The value of an expression E at a time tl in the 
history can be obtained using the past operator, past(E, tl). There are four types of 
events in ASTRAL. A call event, Call(tr1, t1), occurs for an exported transition trl at 
a time tl iff trl was called from the external environment at tl. A start event, 
Start(tr1, t1), occurs for a transition trl at a time tl iff trl fires at tl. Similarly, an 
end event, End(tr1 , t1 ), occurs if trl ends at tl. Finally, a change event, Change(v1 , 
t1), occurs for a variable vl at a time tl iff vl changes value at tl. Note that change 
events can only occur when an end event occurs for some transition. An introduction 
and complete overview of the ASTRAL language can be found in [2] . 

The example system used throughout the remainder of the paper is shown in figure 
1. This system is a circuit that computes the value of a * b + c * d, given inputs a, b, 
c, and d. The ASTRAL specification for the circuit is shown below. 



PROCESS Mult_Add 
EXPORT compute, output 
CONSTANT dur1 : pos_real 
VARIABLE output: integer 
TRANSITION compute(a,b,c,d: integer) 
ENTRY [TIME:dur1] 

TRUE 

EXIT output = a*b + c*d 



AXIOM TRUE 
INVARIANT 



FORALL t1 : time, a, b, c, d: integer 
( Start(compute(a, b, c, d), t1) 

^ FORALL t2: time 

( t1 + dur1 < t2 & t2 < now 
^past(output, t2) = a * b + c * d)) 



3 Sequential Refinement Mechanism 

A refinement mechanism for ASTRAL was defined in [3]. In this definition, an 
ASTRAL process specification consists of a sequence of levels where the behavior of 
each level is implemented by the next lower level in the sequence. Given two 
ASTRAL process level specifications Pu and Pl, where Pl is a refinement of Pu, the 
implementation statement, hereafter referred to as the IMPL mapping, defines a 
mapping from all the types, constants, variables, and transitions of Py into their 
corresponding terms in Pl, which are referred to as mapped types, constants, 
variables, or transitions. Pl can also introduce types, constants and/or variables that 
are not mapped, which are referred to as the new types, constants, or variables of Pl. 
Note that Pl cannot introduce any new transitions (i.e. each transition of Pl must be a 
mapped transition). A transition of Py can be mapped into a sequence of transitions, a 
selection of transitions, or any combinations thereof. 

A selection mapping of the form Ty == Ai & Tl.i I A 2 & Tl .2 I ... I A„ & Tl.„, is 
defined such that when the upper level transition Tu fires, one and only one lower 
level transition Tl.j fires, where Tlj can only fire when both its entry assertion and its 
associated „guard“ Aj are true. 

A sequence mapping of the form Tu == WHEN EntryL DO Tl.i BEFORE Tl .2 
BEFORE ... BEFORE Tl„ OD, defines a mapping such that the sequence of 
transitions Tl.i; Tl.„ is enabled (i.e. can start) whenever EntryL evaluates to true. 
Once the sequence has started, it cannot be interrupted until all of its transitions have 
been executed in order. The starting time of the upper level transition Tu corresponds 
to the starting time of the sequence (which is not necessarily equal to the starting time 
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of Tl 1 because of a possible delay between the time when the sequence starts and the 
time when Tl.i becomes enabled), while the ending time of Tu corresponds to the 
ending time of the last transition in the sequence, Tl ,,- Note that the only transition 
that can modify the value of a mapped variable is the last transition in the sequence. 
This further constraint is a consequence of the ASTRAL communication model. That 
is, in the upper level, the new values of the variables affected by Tu are broadcast 
when Tu terminates. Thus, mapped variables of Pu can be modified only when the 
sequence implementing Tu ends. 

The inter-level proofs consist of showing that each upper level transition is 
correctly implemented by the corresponding sequence, selection, or combination 
thereof in the next lower level. For selections, it must be shown that whenever the 
upper level transition Tu fires, one of the lower level transitions Tu.j fires, that the 
effect (i.e. changes to variables) of each Tu.j is equivalent to the effect of Tu, and that 
the duration of each Tlj is equal to the duration of Tu- For sequences, it must be 
shown that the sequence is enabled iff Tu is enabled, that the effect of the sequence is 
equivalent to the effect of Tu, and that the duration of the sequence (including any 
initial delay after Entryu is true) is equal to the duration of Tu- 

4 Parallel Refinement Mechanism 

In the sequential mechanism, refinement occurs at the transition level, where the 
behavior of each upper level transition can be specified in greater detail at the lower 
level. We now extend the ASTRAL refinement mechanism to include process level 
refinement, which allows a process to be refined as a collection of components that 
operate in parallel. For example, a reasonable refinement of the Mult_Add circuit is 
shown in figure 2. Here, the refinement of the system consists of two multipliers that 
compute a * b and c * d in parallel and an adder that adds the products together and 
produces the sum. This refinement cannot be expressed in the sequential mechanism 
due to the parallelism between the two multipliers. The new parallel mechanism 
introduced below, however, easily expresses this refinement. 



a 

b 

c 

d 




Fig. 1. Mult_Add circuit 



Fig. 2. Refined Mult_Add circuit 



In parallel refinement, an upper level transition may be implemented by a dynamic 
set of lower level transitions. To guarantee that an upper level transition is correctly 
implemented by the lower level, it is necessary to define the events that occur in the 
lower level when the transition is executed in the upper level. It must then be shown 
that these events will only occur when the upper level transition ends and that the 
effect will be equivalent. Like the sequential refinement mechanism of [3], an IMPL 
mapping is used, which describes how items in an upper level are implemented by 
items in the next lower level. The items of the upper level include variables, 
constants, types, and transitions. In addition, the implementation mapping must 
describe how upper level expressions are transformed into lower level expressions. 
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The following sections only discuss the transition mappings. A complete description 
of the IMPL mapping is given in [9]. 

4.1 Parallel Sequences and Selections 

A natural but limited approach to defining parallel transition mappings is to extend the 
sequential sequence and selection mappings into parallel sequence and selection 
mappings. Thus, a „H“ operator could be allowed in transition mappings, such that 
„Pi.trl II P2-tr2“ indicates that trl and tr2 occur in parallel on processes Pi and P 2 , 
respectively. With this addition, the compute transition of the Mult_Add circuit 
could be expressed as the following. 

IMPL(compute(a, b, c, d)) == WHEN TRUE DO 
(M1.multiply(a, b) II M2.multiply(c, d)) 

BEFORE A1 .add(M1 .product, M2. product) OD, 

where Ml and M2 are the multipliers and A1 is the adder. 

Although parallel sequences and selections work well for the example, they do not 
allow enough flexibility to express many reasonable refinements. For example, 
consider a production cell that executes a produce transition every time unit to 
indicate the production of an item. In a refinement of this system, the designer may 
wish to implement produce by defining two „staggered“ production cells that each 
produce an item every two time units, thus effectively producing an item every time 
unit. The upper level production cell Pu and the lower level production cells Pl 1 and 
Pl .2 are shown in figure 3. Note that the first transition executed on Pu is in it, which 
represents the „warm-up“ time of the production cell in which no output is produced. 



PU 



Fig. 3. Production cell refinement 



This refinement cannot be expressed using parallel sequences and selections because 
there is no sequence of parallel transitions in the lower level that corresponds directly 
to produce in the upper level. When produce starts in the upper level, one of the 
lower level produce’s will start and when produce ends in the upper level, one of the 
lower level produce’s will end and achieve the effect of upper level produce, but the 
produce that starts is not necessarily the produce that achieves the effect of the 
corresponding end. 

4.2 Parallel Start, End, and Call Mappings 

The desired degree of flexibility is obtained by using transition mappings that are 
based on the start, end, and call of each transition. For each upper level transition Tu, 
a start mapping „lMPL(Start(Tu, now)) == Startu” and an end mapping 
„IMPL(End(Tu, now)) == Endu“ must be defined. If Tu is exported, a call mapping 
„IMPL(Call(Tu, now)) == Callu” must also be defined. These mappings are defined 
at time now, which is a special global variable that holds the current time in the 
system; thus, the mappings are defined for all possible times. 
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Here, StartL, EhcIl, and CallL are well-formed formulas using lower level 
transitions and variables. For the most part, the end and call mappings will 
correspond to the end or call of some transition in the lower level, whereas the start 
mapping may correspond to the start of some transition or some combination of 
changes to variables, the current time, etc. Call mappings are restricted such that for 
every lower level exported transition Tl, Call(TL) must be referenced in some upper 
level exported transition call mapping IMPL(Call(Tu, now)). This restriction 
expresses the fact that the interface of the process to the external environment cannot 
be changed. For parameterized transitions, only the call mapping may reference the 
parameters given to the transition. Any parameter referenced in a call mapping must 
be mapped to a call parameter of some lower level transition and the corresponding 
start mapping must contain the same transitions as the call mapping. Thus, the start 
and end parameters are taken from the associated set of unserviced call parameters. 

With these mappings, the initialize and produce transitions can be mapped as 
follows. Note that the parallelism between Pl.i and Pl .2 is implied by the overlapping 
start and end times of produce on each process and not by a built-in parallel operator. 



IMPL(Start(initialize, now)) == 

now = 0 & PL,.Start(produce, now) 
IMPL(Start(produce, now)) == 

IF now mod 2 = 0 

THEN P^,.Start(produce, now) 
ELSE P|^j. S*^''*(ptoduce, now) 
FI 



IMPL(End(initialize, now)) == 
now = 1 

IMPL(End(produce, now)) == 

IF now mod 2 = 0 
THEN PL,.End(produce, now) 
ELSE P|^ 2 -End(produce, now) 
FI 



5 The Mult_Add Circuit 



The specification of the refinement of the Mult_Add circuit in figure 2 is shown below 
using the new parallel refinement mechanism. Each multiplier has a single exported 
transition multiply, which computes the product of two inputs. The adder has a single 
transition add, which computes the sum of the two multiplier outputs. 



PROCESS Multiplier 
EXPORT 

multiply, product 
VARIABLE 

product: integer 

TRANSITION multiply(a, b: integer) 
ENTRY [TIME: 2] 

EXISTS t: time 
(End(multiply, t)) 
now - End(multiply) > 1 
EXIT 

product = a * b 



PROCESS Adder 
IMPORT 

Ml, Ml. product. Ml. multiply, 

M2, M2. product, M2. multiply 
EXPORT sum 
VARIABLE sum: integer 
TRANSITION add 
ENTRY [TIME: 1] 

Ml .End(multiply, now) 

& M2.End(multiply, now) 

EXIT 

sum = Ml. product -i- M2. product 



The lower level consists of two instances of the Multiplier process type. Ml 
and M2, and one instance of the Adder process type, Al. The output variable of the 
upper level process is mapped to the sum variable of the adder (IMPL(output) == 
Al.sum). The duration of the compute transition is the sum of the multiply transition 
and the add transition in the lower level (IMPL(durl) == 3). When compute starts in 
the upper level, multiply starts on both Ml and M2. When compute ends in the 
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upper level, add ends on Al. When compute is called in the upper level with inputs 
a, b, c, and d, multiply is called on Ml with inputs a and b and multiply is called on 
M2 with inputs c and d. 

IMPL(Start(compute, now)) == IMPL(End(compute, now)) == A1 .End(add, now) 
M1 .Start(multiply, now) IMPL(Call(compute(a, b, c, d), now)) == 

& M2.Start(multiply, now) M1.Call(multiply(a, b), now) 

& M2.Call(multiply(c, d), now) 



6 Proof Obligations for Parallel Refinement Mechanism 

The goal of the refinement proof obligations is to show that any properties that hold in 
the upper level hold in the lower level without actually reproving the upper level 
properties in the lower level. In order to show this, it must be shown that the lower 
level correctly implements the upper level. ASTRAL properties are interpreted over 
execution histories, which are described by the values of state variables and the start, 
end, and call times of transitions at all times in the past back to the initialization of the 
system. A lower level correctly implements an upper level if the implementation of 
the execution history of the upper level is equivalent to the execution history of the 
lower level. This corresponds to proving the following four statements. 

(V) Any time a variable has one of a set S of possible values in the upper level, the 
implementation of the variable has one of a subset of the implementation of S 
in the lower level. 

(C) Any time the implementation of a variable changes in the lower level, a 
transition ends in the upper level. 

(S) Any time a transition starts in the upper level, the implementation of the 
transition starts in the lower level and vice-versa. 

(E) Any time a transition ends in the upper level, the implementation of the 
transition ends in the lower level and vice-versa. 

If these four items can be shown, then any property that holds in the upper level is 
preserved in the lower level because the structures over which the properties are 
interpreted is identical over the implementation mapping. 

6.1 Proof Obligations 

Instead of proving directly that the mappings hold at all times, it can be shown that the 
mappings hold indirectly by proving that they preserve the axiomatization of the 
ASTRAL abstract machine, thus they preserve any reasoning performed in the upper 
level. This can be accomplished by proving the implementation of each abstract 
machine axiom. The proof obligations are shown in figure 4 and are written in the 
specification language of PVS [4], which will be used to assist the proofs in the future. 

To perform the proofs, the following assumption must be made about calls to 
transitions in each lower level process. 

impLcall: ASSUMPTION 

(FORALL (trjl: transitionJI, t1: time): 

Exported(trJI) AND Call(tr_ll, t1)(t1) IMPLIES 

(EXISTS (tr_ul: transition_ul): (FORALL (t2: time): 

IMPL(Call(tr_ul, t2)(t2)) IMPLIES Call(tr_ll, t2)(t2)) AND 
IMPL(Call(tr_ul, t1)(t1)))) 
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This assumption states that any time a lower level exported transition is called, there is 
some call mapping that references a call to the transition that holds at the same time. 
This means that if one transition of a „conjunctive“ mapping is called, then all 
transitions of the mapping are called. That is, it is not possible for a lower level 
transition to be called such that the call mapping for some upper level transition does 
not hold. For example, consider the mapping for the compute transition of the 
Mult_Add circuit „IMPL(Call(compute(a, b, c, d), now)) == Ml.Call(multiply(a, b), 
now) & M2.Call(multiply(c, d), now)“. In this case, impl_call states that any time 
multiply is called on Ml, multiply is called on M2 at the same time and vice-versa. 

An assumption is also needed to assure that whenever the parameters of an upper 
level exported transition are distributed among multiple transitions at the lower level, 
the collection of parameters for which the lower level transitions execute come from a 
single set of call parameters. For example, in the Mult_Add circuit, the upper level 
compute transition may be called with two sets of parameters { 1, 2, 3, 4} and {5, 6, 
7, 8} at the same instant. In the lower level implementation, the multiply transition of 
each multiplier takes two of the parameters from each upper level call. Thus, in the 
example, multiply is enabled on Ml for {1, 2} and {5, 6) and on M2 for {3, 4} and 
{7, 8}. Without an appropriate assumption. Ml may choose {1, 2} and M2 may 
choose {7, 8}, thus computing the product for {1, 2, 7, 8}, which was not requested at 
the upper level. The impl_callj'ire _parms assumption given in [9] prevents this. 



impLendl: OBLIGATION 
(FORALL (tr1 : transition, t1 : time): 
IMPL(End(tr1, t1)(t1)) IMPLIES 
t1 > IMPL(Duratlon(tr1))) 
impl_end2: OBLIGATION 
(FORALL (tri: transition, t1: time, t2: 
time): 

t1 =t2 - IMPL(Duration(tr1)) IMPLIES 
(IMPL(Start(tr1, t1)(t1)) IFF 
IMPL(End(tr1, t2)(t2)))) 
impl_trans_mutex: OBLIGATION 
(FORALL (tri : transition, t1 : time): 
IMPL(Start(tr1, t1)(t1)) IMPLIES 
(FORALL (tr2: transition): 
tr2^tr1 IMPLIES 
NOT IMPL(Start(tr2, t1)(t1))) 

AND 

(FORALL (tr2: transition, t2: time): 
t1 < t2 AND 

t2 < t1 + IMPL(Duration(tr1)) 
IMPLIES 

NOT IMPL(Start(tr2, t2)(t2)))) 
impl_trans_entry: OBLIGATION 
(FORALL (tri : transition, t1 : time): 
IMPL(Start(tr1, t1)(t1)) IMPLIES 
IMPL(Entry(tr1, t1))) 
impl_trans_exlt: OBLIGATION 
(FORALL (tri : transition, t1 : time): 
IMPL(End(tr1, t1)(t1)) IMPLIES 
IMPL(Exit(tr1, t1))) 



impl_trans_called: OBLIGATION 
(FORALL (tri : transition, t1 : time): 
IMPL(Start(tr1, t1)(t1)) AND 
Exported(trl) IMPLIES 
IMPL(lssued_Call(tr1, t1))) 
impl_trans_flre: OBLIGATION 
(FORALL (t1 : time): 

(EXISTS (tri : transition): 
IMPL(Enabled(tr1, t1))) AND 
(FORALL (tr2: transition, t2: time): 
t1 - IMPL(Duration(tr2)) < t2 AND 
t2<t1 IMPLIES 

NOT IMPL(Start(tr2, t2)(t2))) 

IMPLIES 

(EXISTS (tri : transition): 
IMPL(Start(tr1, t1)(t1)))) 
impl_vars_no_change: OBLIGATION 
(FORALL (t1 : time, t3: time): 
t1 <t3 AND 

(FORALL (tr2: transition, t2: time): 
t1 <t2 AND t2<t3 IMPLIES 
NOT IMPL(End(tr2, t2)(t2))) 

IMPLIES 

(FORALL (t2: time): 
t1 <t2 AND t2<t3 IMPLIES 
IMPL(Vars_No_Change(t1 , 

t2)))) 

impIJnItlaLstate: OBLIGATION 
IMPL(lnltlal(0)) 

implJocaLaxiom: OBLIGATION 
(FORALL(t1):IMPL(Axlom(t1) 



Fig. 4. Parallel refinement proof obligations 
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In the axiomatization of the ASTRAL abstract machine [9], the predicate 
„Fired(trl, tl)“ is used to denote that the transition trl fired at time tl. If Fired(trl, tl) 
holds, then it is derivable that a start of trl occurred at tl and an end of trl occurred at 
tl + Duration(trl). Additionally, since an end of trl can only occur at tl when 
Fired(trl, tl - Duration(trl)) holds and the time parameter of Fired is restricted to be 
nonnegative, it is known that an end can only occur at times greater than or equal to 
the duration of the transition. In the parallel refinement mechanism, the start and end 
of upper level transitions are mapped by the user, so it is unknown whether these 
properties of end still hold. Since the axioms rely on these properties, they must be 
proved explicitly as proof obligations. The impl_endl obligation ensures that the 
mapped end of a transition can only occur after the mapped duration of the transition 
has elapsed. The impl_end2 obligation ensures that for every mapped start of a 
transition, there is a corresponding mapped end of the transition, that for every 
mapped end, there is a corresponding mapped start, and that mapped starts and 
mapped ends are separated by the mapped duration of the transition. 

The other obligations are the mappings of the ASTRAL abstract machine axioms. 
The impl_trans_mutex obligation ensures that any time the mapped start of a transition 
occurs, no other mapped start of a transition can occur until the mapped duration of 
the transition has elapsed. The impl_tmns_entry obligation ensures that any time the 
mapped start of a transition occurs, the mapped entry assertion of the transition holds. 
The impl_tmns_exit obligation ensures that any time the mapped end of a transition 
occurs, the mapped exit assertion of the transition holds. The impl_trans_called 
obligation ensures that any time the mapped start of an exported transition occurs, a 
mapped call has been issued to the transition but not yet serviced. The 

impl_transj'ire obligation ensures that any time the mapped entry assertion of a 
transition holds, a mapped call has been issued to the transition but not yet serviced if 
the transition is exported, and no mapped start of a transition has occurred within its 
mapped duration of the given time, a mapped start will occur. The 

impl_vars_no_change obligation ensures that mapped variables only change value 
when the mapped end of a transition occurs. The impl_initial_state obligation ensures 
that the mapped initial clause holds at time zero. 

Besides the abstract machine axioms, the local proofs of ASTRAL process 
specifications can also reference the local axiom clause of the process (which is empty 
(i.e. TRUE) in the Mult_Add circuit). Since this clause can be used in proofs and the 
constants referenced in the clause can be implemented at the lower level, the mapping 
of the local axiom clause of the upper level must be proved as a proof obligation. The 
impl_local_axiom obligation ensures that the mapped axiom clause holds at all times. 
In order to prove this obligation, it may be necessary to specify local axioms in the 
lower level processes that satisfy the implementation of the upper level axiom clause. 

To prove the refinement proof obligations, the abstract machine axioms can be 
used in each lower level process. For example, to prove the impl_initial_state 
obligation, the initial_state axiom of each lower level process can be asserted. 

6.2 Correctness of Proof Obligations 

The proof obligations for the parallel refinement mechanism given in figure 4 are 
sufficient to show that for any invariant I that holds in the upper level, IMPL(I) holds 
in the lower level. Consider the correctness criteria (V), (C), (S), and (E) above. (V) 
is satisfied because by impl_initial_state, the values of the implementation of the 
variables in the lower level must be consistent with the values in the upper level. 
Variables in the upper level only change when a transition ends and at these times, the 
implementation of the variables in the lower level change consistently by 
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impl_trans_exit. (C) is satisfied because the implementation of the variables in the 
lower level can only change value when the implementation of a transition ends by 
impl_vars_no_change. The forward direction of (S) is satisfied because whenever an 
upper level transition fires, a lower level transition will fire by impl_trans_fire. The 
reverse direction of (S) is satisfied because whenever the implementation of a 
transition fires in the lower level, its entry assertion holds by impl_trans_entry, it has 
been called by impl_trans_called, and no other transition is in the middle of execution 
by impl_trans_mutex. (E) is satisfied because (S) is satisfied and by impl_endl and 
impl_end2, any time a start occurs, a corresponding end occurs and vice-versa. 

More formally, any time an invariant I can be derived in the upper level, it is 
derived by a sequence of transformations from I to TRUE, 1 U fi/^i Ii 1“ a/ai ■■■ 
^ fn/an TRUE, where each transformation f j&i corresponds to the application of a 
series fi of first-order logic axioms and a single abstract machine axiom aj. Since the 
implementation of each axiom of the ASTRAL abstract machine is preserved by the 
parallel refinement proof obligations, a corresponding proof at the lower level 
IMPL(I) H fivimpui IMPL(Ii) H t 27 impLa 2 - fnvimpUn TRUE Can be constructed by 
replacing the application of each abstract machine axiom ai by impl_ai. Additionally, 
each series fi of first-order logic axioms is replaced by a series f;' that takes any 
changes to the types of variables and constants into consideration. 

7 Proof of Mult_Add Circuit Refinement 

This section shows the most notable cases of the parallel refinement proof obligations 
for the Mult_Add circuit. The full proofs can be found in [9]. The obligations below 
were obtained from the corresponding obligations in figure 4 by expanding the IMPL 
mapping appropriately, replacing quantification over transitions with the actual 
transitions of the Mult_Add circuit, rewriting the Curried PVS form (e.g. Start(trl, 
tl)(t2)) to its ASTRAL equivalent (e.g. past(Start(trl, tl), t2)), and performing some 
minor simplifications. Eor the impl_end2 obligation, the following must be proved. 

FORALL t1 : time 

( past(M1 .Start(multiply, t1 - 3), t1 - 3) 

& past(M2.Start(multiply, t1 - 3), t1 - 3) 
past(A1.End(add, t1), t1)) 

Eor the forward direction, it must be shown that add ends on A1 at tl, thus starts at tl 
- 1. Erom the antecedent, multiply ends on both Ml and M2 at tl - 1 so the entry 
assertion of add holds on A1 at time tl - 1. A1 must be idle or else from the entry of 
add, multiply ended in the interval (tl - 2, tl - 1), which is not possible since multiply 
was still executing on Ml and M2 in that interval. Therefore, add starts at tl - 1 on 
Al, thus ends at tl. The reverse direction is similar. 

Eor the impl_trans_exit obligation, the formula below must be proved. 

FORALL tl : time 

( past(A1 .End(add, t1), tl) 

FORALL a, b, c, d: integer 

( past(M1 .Start(muitipiy(a, b), tl - 3), tl - 3) 

& past(M2.Start(muitipiy(c, d), tl - 3), tl - 3) 
past(A1 .sum, tl) = a * b -I- c * d)) 

By the exit assertion of add, past(Al.sum, tl) = past(Ml. product, tl - 1) H- 
past(M2. product, tl - 1). From the entry of add, multiply ends on both Ml and M2 at 
tl - 1. Since multiply ends on Ml and M2 at tl - 1, it starts on Ml and M2 at tl - 3 
for two pairs of parameters (a, b) and (c, d), respectively, which were provided by the 
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external environment. By the exit assertion of multiply, past(Ml. product, tl - 1) = a * 
b and past(M2. product, tl - 1) = c * d, so past(Al.sum, tl) = a * b + c * d. Thus, 
impl_trans_exit holds. 

The impl_trans_fire obligation is given below. 

FORALL tl : time 

( EXISTS t2: time 
( t2 < tl 

& past(M1 .Call(multiply, t2), tl ) 

& past(M2.Call(multiply, t2), tl) 

& FORALL t3: time 

( t2 < t3 & t3 < tl 

-> ~ ( past(M1 .Start(muitiply, t3), t3) 

& past(M2.Start(muitipiy, t3), t3)))) 

& FORALL t2: time 

( tl - 3 < t2 & t2 < tl 
^ ~ ( past(M1.Start(muitiply, t2), t2) 

& past(M2.Start(muitipiy, t2), t2))) 
past(M1 .Start(muitiply, tl ), tl ) 

& past(M2.Start(muitipiy, tl), tl)) 

To prove this obligation, it is first necessary to prove that Ml.Start(multiply) and 
M2.Start(multiply) always occur at the same time. This can be proved inductively. At 
time zero, both Ml and M2 are idle. By impl_call, if multiply is called on either Ml 
or M2, multiply is called on both Ml and M2. At time zero, multiply cannot have 
ended, thus the entry assertion of multiply is true, so if both are called, both fire. If 
neither is called, then neither can fire. For the inductive case, assume 

Ml.Start(multiply) and M2.Start(multiply) have occurred at the same time up until 
some time TO. Suppose multiply occurs on Ml (the M2 case is similar), then Ml was 
idle, multiply has been called since the last start, and it has been at least one time unit 
since multiply ended on Ml. M2 cannot be executing multiply at TO or else Ml must 
also be executing multiply by the inductive hypothesis, thus M2 must be idle. 
Similarly, it must have been at least one time unit since multiply ended on M2. By 
impl_call, multiply must have been called on M2 since it was called on Ml. Thus, 
multiply is enabled on M2, so must fire. Therefore, Ml.Start(multiply) and 

M2.Start(multiply) always occur at the same time. Based on this fact, the following 
two expressions are equivalent. 

FORALL t3: time FORALL t3: time 

( t2 < t3 & t3 < tl ( t2 < t3 & t3 < t1 

-> ~ ( past(M1 .Start(multipiy, t3), t3) ^ ~past(M1 .Start(muitiply, t3), t3) 

&past(M2.Start(muitipiy, t3), t3))) & ~past(M2.Start(multiply, 13^ t3)) 

Since nothing has started in the interval (tl - 3, tl), nothing can end in the 
interval (tl - 1, tl + 2), thus the entry assertion of multiply on Ml is satisfied at tl. 
Since the entry of multiply holds, multiply has been called but not yet serviced, and 
Ml is idle, multiply starts on Ml at tl. Since multiply always starts on both Ml and 
M2 at the same time as shown above, impl_trans_fire holds. 

The remaining proof obligations were all proved in a straightforward manner. 
Therefore, the lower level is a correct refinement of the upper level and the 
implementation of the upper level invariant, shown below, holds in the lower level. 
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FORALL t1 : time, a, b, c, d: integer 
( M1 .Start(muitiply(a, b), t1 - 3) 

& M2.Start(muitiply(c, d), t1 - 3) 

^ FORALL t2: time 

( t1 + dur1 < t2 & t2 < now 

past(A1 .sum, t2) = a * b + c * d)) 

8 Parallel Phone System 

The previous example has shown that the parallel refinement mechanism can express 
the parallel implementation of a simple system in a simple and straightforward 
manner. Furthermore, the proof obligations for a simple implementation were 
themselves simple. In this section we briefly outline how our mechanisms can be 
applied to the specification and refinement of a much more complex case such as the 
control of a phone system. 

The system considered here is a slightly modified version of the phone system 
defined in [2]. It consists of a set of phones that need various services (e.g. getting a 
dial tone, processing digits entered into the phone, making a connection to the 
requested phone, etc.) as well as a set of central controls that perform the services. 
Due to space limitations, this example cannot be described in full detail. Thus, we 
limit ourselves to an informal description of the main steps of the refinement process 
and refer the interested reader to [9] for the complete description and proof. 

The specification of the central control, which is the core of the whole system, is 
articulated into three layers. The goal of the top level is to provide an abstract and 
global view of the supplied services in such a way that the user can have complete and 
precise knowledge of the external behavior, both in terms of functions performed and 
in terms of service times, of the central control but the designer still has total freedom 
on implementation policies. In fact, as a result, the description provided in [2] is just 
an alternative implementation of the top level description given here, which differs 
from this version in that services are granted sequentially rather than in parallel. 

To achieve our goal (i.e. to allow the implementation of services both 
asynchronously in parallel and strictly sequentially, as suggested by figures 5 and 6), 
the top level is specified such that a set of services can start and a set of services can 
end at every time unit in the system (for simplicity we assume discrete time). In these 
figures, Ti_si.Pk denotes providing service si to phone k. 

The service of a phone is split into the beginning of servicing and the completion 
of servicing through two transitions: Begin_Serve and Complete_Serve. In other 
words, instead of assigning ASTRAL transitions to single services or groups thereof, 
we only make the beginning and the end of services visible at the top level. In this 
way, we do not commit too early to a fixed duration of the implementation of the 
service, stating only when a service will begin and when it will be completed. Thus, 
the durations of Begin_Serve and Complete_Serve are set to „serve_dur“, where 
2*serve_dur is chosen to be a divisor of the duration of every service. 

A parameterized variable „serving(P)„ records when each phone P began being 
serviced so that it can complete being serviced at the appropriate time. When 
serving(P) changes to true for a phone P at time t, P began being served at t - 
serve_dur. Thus, when the duration of the function that was serving the phone elapses 
from this time, Complete_Serve carries out the effect of the function on the phone’s 
state and resets serving for that phone to false. 
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1 Tl_sl.Pl ~| 

^ Tl_sl.P2 



T2_s2.Pl 



1 T2_s2.P2 I ► 

1 Tl_sl.Pl I Tl_sl.P2 I T2_s2.Pl | T2_s2.P2 | ► 



Fig. 5. Parallel implementation of 
different services on several phones 



Tl_sl.Pl I Tl_sl.P2 I T2_s2.Pl | T2_s2.F2 ► 

Fig. 6. Sequential implementation of 
different services on several phones 




Fig. 7. Implementation of the phone state 



To allow both a sequential and a parallel implementation, it is necessary for the 
top level specification to allow the possibility of multiple actions occurring at the 
same time without actually requiring multiple actions to occur. This is achieved by 
limiting the number of phones that can be serviced at any given time to be less than a 
constant „K_max“. In the sequential refinement, K_max is mapped to one, indicating 
that only one phone at a time can be serviced. In the parallel refinement, K_max is 
mapped to the sum of the capacities of the individual servers, indicating that as many 
phones as it is possible for the servers to serve can be serviced in parallel. 

Let us now look at the parallel implementation of the top level central control. As 
mentioned earlier, this is achieved through two refined layers. In the first refinement, 
the central control is split into several parallel processes, each of which is devoted to a 
single service of the top level central control. Thus, there is a process devoted to 
giving dial tone, a process devoted to processing entered digits, and so on. Each one 
of these processes executes two transitions that correspond to Begin_Serve and 
Complete_Serve at the top level. 

The main issue in this step is the mapping of the global state of the central control 
into disjoint components to be assigned to the different lower level parallel processes. 
That is, the „Phone_State(P)“ variable in the top level, which holds the state of each 
phone P (Phone_State can take the values idle, ready _to_dial, ringing, ...), needs to be 
split among all the servers in the lower level. 

In the ASTRAL model, however, only a single process can change the value of a 
variable, thus it is not possible to let all of the lower level servers change the same 
variable directly. A solution to this problem is to split Phone_State into a set of 
„timestamp“ variables, with one timestamp for each possible state of a phone. Each 
server is then allocated the timestamp variables associated with the phone state(s) it is 
responsible for. The state of a phone is the state associated with the timestamp that 
has last changed among all the servers. Eigure 7 illustrates such a state variable 
mapping. In this figure, each component is managed by a different process and the 
current state of the phone is „ringing“ because the corresponding timestamp 
component holds the maximum value. 

Einally, in the third layer of the central control, each second level server is refined 
by a parallel array of „microservers“, where each microserver is devoted to processing 
the calls of a single phone. Each microserver picks a phone from the set of phones 
waiting for the service according to some, possibly nondeterministic, policy and 
inserts its identifier into a set of served phones through a sequence of two transitions. 
The union of the elements of these sets over all the microservers implements the set of 
phones that are being served on the upper level server. 
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This example demonstrates that the parallel refinement mechanism can be used to 
express very complex parallel implementations. Not surprisingly, such generality is 
obtained at the cost of complicating the proofs of the proof obligations as shown in the 
major proofs of the phone system refinement, which were completed in [9]. We are 
confident that the approach adopted in this and other examples can be applied in a 
fairly similar way to a collection of real-life cases. As a result, we should obtain a 
general and systematic method for driving the specification and refinement of parallel 
and asynchronous systems. 

9 Conclusions, Future Work, and Acknowledgments 

ASTRAL aims to provide a disciplined and well-structured way of developing real- 
time systems. To achieve this goal it stresses modularization and incremental 
development through several refinement levels. In this paper, we presented an 
approach to accomplish these refinement steps in a flexible, general, and yet rigorous 
and provably correct way. A key feature of the proposed mechanism is the 
exploitation of parallelism so that global actions at a high level of abstraction may be 
described as individual transitions that can be refined at a lower level as several 
concurrent and cooperating activities. Our approach allows more generality and 
flexibility than the few independent ones available in the literature, which are more 
algebraic in nature (for an up-to-date survey of formal refinement methods see [5]). 

Although our experience in the application of the mechanisms to problems of 
practical interest is still limited, we have already developed a number of case studies 
that show that the approach naturally scales up. Besides those summarized in this 
paper, we also mention the management of a hydroelectric reservoir system based on a 
real-life project. Early methods guiding the user throughout the development of real- 
life cases have already been extracted from these experiences [9]. 

As usual, when moving towards complex applications, the support of suitable tools 
is fundamental. ASTRAL is already equipped with several prototype tools [10] that 
allow the user to edit and manage complex specifications as well as providing support 
for their analysis. In particular, proof obligations can be automatically produced from 
specifications, and proofs are supported by both model checking and deductive 
facilities. The model checker can check the critical requirements of a particular 
instance of a specification over a finite time interval. ASTRAL has been encoded into 
the language of the PVS theorem prover to support deductive reasoning. 

The ASTRAL toolset currently supports the sequential refinement mechanism of 
[3], but does not yet support the parallel refinement mechanism of this paper. To 
support the new mechanism, the design portion needs to incorporate a slightly 
different specification structure, an algorithm is needed to transform upper level 
expressions to lower level expressions using the implementation mapping, and the 
proof obligations must be incorporated into the current ASTRAL-PVS library for use 
with the theorem prover. It may be possible to use the PVS rewriting mechanism 
directly to transform upper level items to lower level items. This work is currently 
under way. In addition to tool support, more parallel refinements will be developed to 
test the expressiveness and applicability of the new parallel mechanism. 

The authors would like to thank Klaus-Peter Loehr for his participation in the 
development of the parallel mechanism and Giovanna Di Marzo for her valuable 
comments. This research was partially supported by NSF Grant No. CCR-9204249 
and by the Programma di scambi internazionale of the CNR. 
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Abstract. The topic of the present work is the specification of system Eault 
Tolerance (ET). ET is considered a valid technique for increasing the 
dependability of critical automation systems by adding them the ability to 
operate in presence of faults. Two basic considerations stimulated the 
development of the present work. Firstly although a considerable amount of 
concepts and theory have been published around FT, a full-organized method 
supporting their application to the FT needs of a specific system is still missing. 
Furthermore, the availability of a methodology oriented to the specification of 
system FT is especially useful in view of integrating available FT software 
layers according to specific system needs. Goal of the present work is therefore 
to develop a methodology for the FT specification, to be used as a tool 
supporting the configuration of the tailorable FT software layer, which is 
currently under development within the TIRAN Project'. The presented 
approach to the FT specification is based on a combined use of two general- 
purpose specification methods: the UML (Unified Modeling Language) 
graphical method and the TRIO (Tempo Reale ImplicitO) temporal logic. The 
main novelty of the proposed method consists in the identification and 
organization of a sequence of specification steps, which drive the industrial user 
in collecting and analyzing system dependability requirements and then in 
designing FT solutions, possibly tailoring already existing and configurable FT 
mechanisms. 



1. Introduction 

Purpose of this work is the construction of a methodological scheme in support to the 
development of dependable systems. Deterministic aspects of dependability 
properties, which concern how the system faces the possibility of faults independently 
by their occurrence probabilities, are specifically addressed. With respect to high- 



' The TIRAN (Tailorable fault toleRANce frameworks for embedded applications) Esprit 
Project is partially funded by the IT Programme of the Commission of the European 
Communities as project n° 28620. The partners of the TIRAN Project are ENEL-R&D 
(Italy), SIEMENS (Germany), TXT Informatica (Italy), EONIC Systems (Belgium), Katholic 
University of Leuven (Belgium) and University of Turin (Italy). 

T. Maibaum (Ed.): EASE 2000, LNCS 1783, pp. 82-96, 2000. 

© Springer-Verlag Berlin Heidelberg 2000 
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level dependability means like fault prevention, fault removal, fault forecasting and 
fault tolerance the scheme focuses on fault tolerance (FT) techniques which increase 
system reliability, availability and integrity by preventing system faults from 
producing system failures [Lapr95]. 

Each system stating a set of FT requirements has to be realised by adopting a specific 
FT solution. More or less explicitly high level FT requirements express constraints on 
the FT strategy to be adopted and/or about suitable configurations/compositions of FT 
steps and their related mechanisms. 

As an example, let us consider the following high level FT requirement: 

“When a hardware fault occurs and remains unrepaired for at least S time units, the 
system must be able to find the damaged part and put it off-line. ” 

The above requirement expresses a FT strategy addressing hardware faults composed 
by FT steps such as error detection (“When a hardware fault occurs...”), fault 
diagnosis {“...the system must be able to find the damaged part...”) and system 
reconfiguration {“...and put it off-line.”). The triggering of the FT strategy is due to 
output from the error detection step and conditioned by the duration of fault 
permanence in the unrepaired state {“...and remains unrepaired for at least 5 time 
units. . . ”), therefore requiring some time-out mechanism. 

The proposed methodological scheme concentrates on the first steps in the 
development of a FT solution, which concern high level FT requirement specification 
and how they constrain the FT solution. It supports the collection and organization of 
FT requirements into a semi-formal model and their formal specification and analysis. 
The work is part of the TIRAN Esprit Project whose main objective is the 
development of a tailorable software framework providing a set of FT mechanisms 
amenable for real-time and distributed automation systems [Bott99]. In the context of 
the TIRAN project, the main goal of this work is the definition of a methodological 
support addressed to both 

• application designers, in capturing system-specific high level FT requirements 

• users of the TIRAN framework, in tailoring its use to the FT needs of the particular 
system. 

The methodological scheme is based on a systematic organization of well-known 
dependability concepts (due to Laprie [Lapr95], [Fapr98] and recent R&D 
experiences [EFTOS97] about FT flexible solutions. The novelty of the approach 
consists of the definition of a methodology organized into a sequence of steps, which 
drive the user in first collecting and analyzing his/her FT requirements and then 
composing his/her FT solutions. 

The whole scheme, overviewed in section 2, is composed by four distinct 
specification supports which make use of informal, semi-formal and formal 
techniques at the aim of producing, for a given system, a certifiable specification of 
its FT requirements. The present paper summarizes the first three steps of the scheme 
fully presented in [TIRAN99]: 

1. in the first step, described in section 3, the FT specification is based on the UML 
[UML97a] [UML97b] semi-formal approach, as supported by the tool Rational 
Rose [Rose98] 

2. the second step, described in section 4, exploits the TRIO formal language 
[Ciap97a] to express the requirements related to FT specification in a formal way 

3. the third step exploits the formal techniques made available by TRIO to perform 
formal analyses on the FT requirements. 
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The scheme has been applied to model the FT requirements of an ENEL system, the 
Primary Substation Automation System (PSAS) which consists of different modules 
managing an electric substation^. The proposed application combines protection, 
command and control, monitoring and supervision capabilities and is a good 
representative for most of the dependability requirements of the energy field, in terms 
of integrity, security, availability and EMI immunity. It also demands for distributed 
and heterogeneous platforms with High Performance Computing capabilities. 
However, due to space reasons, only one example of the application of the formal part 
of the ET scheme to the PSAS system has been reported in sections 4 and 5. 



2. Scheme Overview 

In order to allow its wide exploitation, the scheme has been developed by separating 
the use of semi-formal techniques for specifying FT requirements from the use of 
fully formal methods for performing formal V&V activities on FT requirements. 

To non-formal specifiers the scheme proposes a model for the specification of FT 
requirements based on the Unified Modeling Language or UML [UML97a] 
[UML97b], in its version supported by the tool Rational Rose [Rose98]. As UML is 

• an object-oriented graphical language => therefore highly expressive 

• an OMG standard a pre-requisite to its industrial spreading 

• supported by visual modeling tools therefore an “easy to learn” technology 

• strongly emerging in the market of semi-formal methods for system design 

it showed to be an adequate mean for communicating the basics of the generic scheme 
for the specification of FT requirements, as well as for applying the scheme on 
specific FT systems. 

The UML-based support to FT specification represents an entry-level use of the 
scheme, which requires a very low overhead, paid back by significant improvements 
in the specification inter-operability. It is centered on 

• System composition, introducing system components/functions and their attributes 

• Fault/Error/Failure (FEF) classes characterized by hierarchical relationships, 
attributes and associations with system components/functions 

• FT step classes characterized by hierarchical relationships, attributes and 
associations with fault classes. 

As a second step the scheme proposes to formalize the specification of FT 
requirements, thus endowing FT requirements with all the specification and V&V 
benefits recognized to formal methods [Rush95] [NASA95] [MOD91]. A specific 
formal method called TRIO is used to specify FT requirements. TRIO (Tempo Reale 
Implicito) [Ciap97a] is a product of ENEL research conceived for the specification of 
real time systems, also experimented by industries like Ansaldo, Volvo and Sextant. 



^ A joint project with the ENEL Distribution Division is ongoing to renew the existing PSAS. 
One of the goals of this joint project is to improve the efficiency and quality of service, by 
increasing the system dependability and by reducing its costs. Target plants are about 2000 
existing and new Primary Substations (PS). 
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The TRIO formalization is finalized to produce a fully formal version of the FT 
requirement specification expressed in TRIO forms^. 

The third step of the scheme makes use of TRIO formal techniques to perform V&V 
activities on the FT requirement specification. Specifically two levels of support to 
V&V are provided: 

• Level A: static analysis dealing with the V&V of the fault tolerance strategic plan 

• Level B: dynamic analysis dealing with the V&V of system behaviors. 

The fourth, final step of the scheme establishes generic links between system-specific 
FT requirements and their related FT solutions. A central issue towards FT design is 
the identification of appropriate FT mechanisms. There are several mechanisms 
supporting fault tolerance. Each mechanism may be used to realize several types of 
FT steps and may contribute fulfilling several system-specific FT requirements. FT 
mechanisms may be explicitly referred in the FT requirements of a specific system, 
but it may also be the case that the requirements do not refer to them. Some FT 
mechanisms could have alternative configurations, which need to be set in the FT 
design specification. The following design activities have to be considered by the 
fourth step of the methodology: 

• choice of FT mechanisms: a set of FT mechanisms fulfilling the requirements has 
to be identified depending on the specified FT steps and design constraints 

• choice of the target platform 

• verification of design constraints: time/space/redundancy constraints stated in the 
requirements have to be satisfied by the correspondent bounds associated with the 
selected FT mechanisms and platform. 

The instantiation of this step of the scheme on a specific application represents a 
support to a system-specific tailoring of the TIRAN framework driven by FT 
requirements. However, as this step has not been developed in detail yet, it will not be 
further described in the rest of the paper. 



3. UML-Based Support to FT Specification 

The first step of the methodological scheme is expressed in the UML notation. This 
means that UML models, to be intended as meta-models to be instantiated by each 
application of the methodology to a specific FT system, capture methodological 
guidelines. The UML methodological step consists in a set of class hierarchies 
distributed into a structure of Packages'*. Each Package encapsulates a set of inner 
packages/classes and their relationships, visualized by means of Package/Class 
Diagrams.^ 



^ The possibility of supporting the non-formal specification of FT requirements by adopting the 
TRIO graphical editing capabilities [Bert97] has been investigated, this choice allowing the 
automatic integration of the semi-formal and formal steps of the scheme. However, in order 
to favor a wide usability of the first, semi-formal step of the methodology in industrial 
contexts, the adoption of the UML standard notation has been preferred. 

* All the words referring to the UML terminology are written in bold face. 

^ Due to space constraints, this section visualizes only a simple example of the UML diagrams 
built by using the tool Rose but visualizes just one UML diagram. The application of the 
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The top-level Package is named Methodology^ and includes three Packages, namely 

1. System Model addressing system requirements relevant to FT specification 

2. FEF (Fault Error Failure) Model supporting the description of fault/error/failure 
classes and modeling the FEF chain 

3. FT Strategy Model concerning the identification of FT steps. 

According to the object-oriented approach, using the UML scheme for specifying FT 
requirements of a given system means 

• to select sub-parts of the scheme models which are relevant for the specific system 

• to assign values to class attributes from the scheme models 

• to refine/specialize sub-parts of models from the scheme. 



3.1 System Model 

The Package System Model includes four inner Packages supporting 

• the definition of the conceptual structure of an FT system, i.e. the identification of 
(classes of) its components (Package Composition) 

• the association of functions to system components (Package Functions) 

• the association of real time requirements to system components and/or functions 
(Package Time Requirements) 

• the association of dependability attributes to system components and/or functions 
(Package Dependability). 

The model of a specific system is obtained specializing classes provided in the System 
Model and representing system-specific components, functions, time constraints, 
attributes and associations. 

The Package Composition concerns system structure. The definition of system 
composition supports system partitioning in fault confinement area, which establish 
independence among faults at the aim of avoiding fault propagation. As the system 
structure is typically system-specific, it will be mainly defined at application level. 
The methodological level may provide generic structures for categories of systems. 
By addressing in particular the category of automation systems, the very basic meta- 
structure in Fig. 1 is made available defining 

• the decomposition of the class Automated System into Automation System and 
Plant (the field) as a UML aggregation relationship 

• the decomposition of the classes Automation System and Plant in Automation 
Component and Plant Component, respectively 

• the interface between Automation Component and Plant Component as a UML 
association called commands 

• the class Automation Operator (which may be local or remote) associated with an 
Automation Component by the association interfaces. 

As far as system functions are concerned, the methodology provides a very simple 
meta-model, which associates system functions to system components and operators.’ 
Communication functions are characterised by the following attributes: 



UML scheme to the PSAS system has been omitted here and the interested reader may refer 
to Chapter 7 of [TIRAN99] where a step by step instantiation of the scheme is reported. 

* All the words referring to element identifiers of the UML model are written in italic face. 
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Automation Operator 
♦location : local, remote 



Fig. 1.: the Main Class Diagram in the Package Composition. 



• Transmission: the mode in which data are transmitted 

• Channel: the type of physical support to communication 

• Bandwidth: the information quantum supported by the channel in the time unit 

• Location that distinguishes communications internal to a component from 

communications towards the plant, remote systems/operators, local 

components/operators. 

The Package Time Requirements identifies two attributes, which are considered 
particularly relevant for the FT specification of real time systems: 

• the attribute cycle time (Tc) refers to the interaction between the 
system/component and its external environment (the plant) 

• the attribute execution time (Texec[f]) which is the (maximum) response time 
required by a function f 

• cycle and execution times are related by Tc < Min (Texec[f]). 

In the case of automation systems the values of these attributes are tightly coupled 
with the real time constraints stated by the plant process on the automation system 
and their definition greatly influences the instantiation of the appropriate FT strategy 
with its associated mechanisms. 

The methodology considers dependability attributes whose quantitative or 
qualitative estimates may be provided. Both repairable and non-repairable dependable 
systems are characterized by the following attributes: 

• criticality: a qualitative estimate of the risk consequent to a failure of a given 
function/component/system. Its type is an enumerative that identifies criticality 
levels. A three-level criticality scale may be adequate for most critical domains 



’ A more detailed model for the Package Functions could be provided by identifying a set of 
generic classes of automation functions such as monitoring, command and control. 
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• complexity: a qualitative estimate of the complexity degree of the system. Its type 
is an enumerative, which identifies complexity levels. Complexity levels have to 
be determined on a strictly system-specific base 

• MTTF (MeanTimeToFailure): the expectation of the mean time to failure. 

In repairable systems/components three other dependability attributes may be added: 

• MTTR (MeanTimeToRepair): the expectation of the time to restoration 

• MTBF (MeanTimeBetweenFailures): the expectation of the time between two 
failures 

• Availability: the probability that the system is ready for specified usage. 

Dependability attributes may be defined at system/component/function level. 



3.2 Fault Error Failure Model 

The FaultErrorFailure (FEF) model captures general concepts on the fault theory 
partially expressed in the literature and partially derived from previous experience. 
Three different Packages {Fault Model, Error Model, Failure Model) compose the 
EEF model, each package characterizing a different view of a fault evolution, from its 
appearance to its recovery and/or repair. 

Faults are error causes that usually affect a system component but then may 
propagate to other components through their interactions. 

The Package Fault Model contains a class diagram representing the fault classification 
due to Laprie [Laprie98]* as a fault hierarchy. The root class Fault of the inheritance 
tree describes a generic fault in terms of the following attributes: 

• fault rate: frequency of a fault occurrence 

• location: faults may affect three logical parts of a system component, namely 
memories (MEM), elaboration units (ELAB) and communication units (COM) 

• latency: the length of time between the occurrence of a fault and the appearance of 
the corresponding error. 

The first level of the inheritance tree distinguishes Physical Fault from Design Fault. 
Physical faults may be either Permanent Fault or Temporaneous Fault. 

Permanent physical faults are specialised by the following sub-classes: 

• DevPerm Fault: internal, permanent faults due to the development phase 

• Opint Fault: internal, operational faults that have their origin within hardware 
components and are constantly active 

• OpEx Fault: external, operational faults induced on the system by the physical 
environment 

Temporaneous physical faults are specialised by the following sub-classes: 

• DevTemp Fault: internal, temporary faults due to the development phase 

• Intermittent Fault: internal physical defects that become active depending on a 
particular pointwise condition 

• Transient Fault: faults induced by environmental phenomena 



Only those classes that are relevant with respect to the FT scope have been included. 
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Design faults are specialised into 

• Systematic Fault: accidental, permanent faults (flawed algorithms) that 

systematically turn into the same errors in the presence of the same input 
conditions and initial states 

• Intentional Fault: intentional, though not malicious, faults (basically compromises 
introduced at design time). 

Faults are related to system components by a multiple association named location. 

Errors are deviations from the correct state of the system. They are caused by faults 
affecting system components and are related to some functions of the faulty 
component. The model assumes that errors affect locally the functions of the faulty 
component before propagating to another interacting component. 

The Package Error Model contains a class diagram representing an error hierarchy 
that is especially useful for the associations between FT mechanisms and the kind of 
errors they are able to manage. 

The root class Error introduces the following basic error attributes: 

• latency, the length of time between the occurrence of an error and the eventual 
appearance of the corresponding failure 

• PE: an estimate of the Probability of the Error. 

The first level of the error hierarchy identifies three error sub-classes, namely 
Processing Error, Communication Error and Memory Error. A Processing Error may 
be sub-classified by one of [Runtime Error, Late Processing Error, Memory Violation 
Error, Corrupted Processing Error]. A Communication Error may be sub-classified 
as one of [Late Communication Error, Corrupted Communication Error, Disordered 
communication Error]. Additional attributes are introduced locally to error sub- 
classes. In particular a BER (Bit Error Rate) attribute is associated to the class 
Corrupted Communication Error. 

Errors are related to system functions by a multiple association named location. 

Eailures are deviations of the service delivered by the system from fulfilling its 
intended function. The root class Eailure of the inheritance tree in the Package Eailure 
Model is characterized by the following basic attributes: 

• PE: an estimate of the Probability of the Eailure 

• criticality: consequences on the environment or failure criticality level. The failure 
criticality level of a specific class of failure influences the specification of its 
related failure mode assumption. 

The different failure mode assumptions generate the following failure classes 
[Cri91]‘*: 

• Omission Eailure: it occurs when an agreed reply to a well-defined request is 
missing. The request appears to be ignored 

• Timing Failure: it occurs when the service is supplied, though outside the real-time 
interval agreed upon in the specification. Sub-classes are Early Timing Failure and 
Late Timing (or Performance) Failure 

• Response Failure: it occurs when the system provides a wrong response. Sub- 
classes are Value Failure (when the system supplies an incorrect output) and State- 
transition Failure (when the system executes an incorrect state transition) 

• Crash Failure: it occurs when the system continuously exhibits omission failures. 
Sub-classes are Pause-crash Failure (the system restarts in the state it had before 



^ The failure classification is an updated version of that reported in [TIRAN99]. 
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its crash). Halting-crash Failure (the system never restart), Amnesia-crash Failure 
(a restarted system re-initializes itself wiping out the state it had before its crash) 
and Partial Amnesia-crash Failure (some part of a system's state is re-initialized 
while the rest is restored to its value before the crash). 

The cause-effect relationships in the chain fault error failure fault are 
captured by a UML class diagram named FEF Chain. The cause-effect association 
between a fault type and its provoked error type considers the value of the attribute 
location in the causing fault. Thus, for example, a fault localized on the memory of a 
system component may propagate as a memory error on some function of that 
component. An error may propagate into a failure and a failure may propagate into a 
fault located anywhere on a component related to the original faulty component. 



3.3 FT Strategy Model 

The UML model of the fault tolerance strategy proposed by the methodology includes 
the classification of FT steps due to Laprie [Laprie95]. Some extensions to that 
classification have been introduced in order to distinguish some FT steps concerning 
faults from steps belonging to the error processing family. 

Any number of FT steps classified as fault processing, error processing and fault 
treatment may carry out fault tolerance. 

Fault Processing aims at avoiding systematically the propagation of fault effects and 
includes two specialized sub-steps, namely 

• Fault Masking: masks the fault using the available redundancy to enable the 
delivery of an error-free service. It does not assume error detection 

• Fault Containment: prevents propagation of fault effects by means of either spatial 
(Permanent Containment) or temporal redundancy (Temporary Containment). 
Spatial redundancy may be on information (Local Containment), hardware or 
software (Global Containment) units 

Error processing aims at removing errors from the computational state (if possible, 
before failure occurrence) and includes the following FT steps: 

• Error detection: identifies states as being erroneous 

• Error diagnosis: assesses the damages caused by error propagation before 
detection 

• Error isolation: isolates the erroneous component from the other part of the system 
to prevent error propagation 

• Error recovery: performs recovery after detection and includes 

• Compensation: recovery is performed using the present (erroneous, internal) state 

that contains enough redundancy to enable the delivery of an error-free 
service. Requires error detection 

• Eorward recovery: recovers to a future state 

• Backward recovery: recovers to a past state 

Fault treatment aims at assuring that the system fails according to the stated failure 
modes and at preventing faults from being re-activated and includes the following: 

• Failure handling: performs a set of actions required to fulfil a given failure mode 

• Fault compensation: after fault containment, it allows the system to provide a 
response to compensate for output of the faulty subsystem 
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• Fault repair, performs repairing actions 

• Fault diagnosis: identifies the cause(s) of error(s) 

• Fault passivation: removes faulty components and includes Reconfiguration, i.e. 
modifies the structure of the system such that non-failed components fulfil the 
system function, possibly at a degraded level. 

FT steps are related to fault/error classes by a multiple association named addresses. 



4. TRIO-Based Support to FT Specification 

The structure of a system FT specification in the TRIO language may be obtained by 
translating in TRIO the system-specific Rose-UML diagrams. Flowever the FT 
formalization includes some parts which have not a correspondence with the semi- 
formal FT specification but whose introduction V&V purposes have motivated. 
Formal methods are typically endowed with automatic analysis capabilities requiring 
that the formalization be adequately instrumented for performing that type of 
analysis'®. 

TRIO is a temporal logic language that supports a linear notion of time: the Time 
Domain is a numeric set equipped with a total order relation and the usual arithmetic 
relations and operators (it can be the set of integer, rational, or real numbers, or any 
interval thereof). TRIO formulae are constructed in the classical inductive way, 
starting from terms and atomic formulas. Besides the usual prepositional operators (& 
for and, I for or, ~ for not) and quantifiers (all, ex), TRIO formulae may be composed 
by using a single basic modal operator called Dist that relates the current time (which 
is left implicit in the formula) to another time instant. Thus the formula Dist (F, t), 
where F is a formula and t a term indicating a time distance, specifies that F holds at a 
time instant at t time units from the current instant. For convenience, TRIO items 
{variables, predicates, and functions) are distinguished into time-independent (TI) 
ones, i.e., whose value does not change during system evolution and time-dependent 
(TD) ones, i.e., those whose value may change during system evolution. Several 
derived temporal operators (ex. Alw(F), Som(F), Becomes(F), Futr(F,t), 
NextTime(F,t)) can be defined from the basic Dist operator through prepositional 
composition and first order quantification on variables representing a time distance. 
TRIO provides object-oriented concepts and constructs, which support writing 
modular reusable specifications of complex systems. Among the most important o-o 
features are the ability to partition the universe of objects into classes, to introduce 
inheritance relations among classes, and to exploit mechanisms such as genericity to 
support the reuse of specification modules and their incremental development. 

Classes denote collections of objects that satisfy a set of axioms. They can be either 
simple or structured -the latter term denoting classes obtained by composing simpler 
ones. A simple class is defined through a set of axioms premised by a declaration of 
all items that are referred therein. Some of such items (declared visible) are in the 



'® The fact that some specification parts are missed in the correspondent semi-formal 
specification does not mean in general that the semi-formal language is unable to express the 
concepts but that that kind of information is relevant for analysis purposes not considered 
during the semi-formal specification. 
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interface of the class, i.e. they may he referenced from outside it in the context of a 
complex class that includes a module that belongs to that class. 

As an example let us consider the following two textual FT requirements of the 
ENEL PSAS system, labeled FR2 and FR19“: 

FR2: “Corruption on input/output, elaboration, memory and internal communications, 
caused by any first fault (transient, intermittent or permanent) must be tolerated 

a) allowing to preserve a working state acceptable and coherent with the history of 

the system 

b) avoiding or handling any loss of control 

c) avoiding to transmit wrong output to the plant, the operator, the remote systems.” 
FR19: “Proper evolution according to the system history needs to be guaranteed: 

a) the evolution must be guaranteed between acceptable states 

b) leaving an acceptable state must be allowed only towards an other acceptable state 

- e.g. by using mechanisms which maintain the current state (judged correct) till 
a confirmation of correctness of the next state (e.g. by using a Stable Memory 
technique [Deco98]) 

c) the transitions between two subsequent acceptable states must be non interruptible 

and without uncertainties - e.g. by an atomic action 

d) evolution must be coherent among the different system components - e.g. by 

synchronizing the state transition of all the components within a single atomic 
action.” 

The combination of ER2a with FR19 demands for a fault masking technique applied 
to the PSAS state. In the TRIO formalization reported below such requirements have 
been fulfilled by a fault masking mechanism called Stable Memory, which integrates 
temporal and spatial (triple modular) redundancy to stabilize the PSAS state. 

Eor the purpose of providing an initial PSAS formal specification, the Rose-UML 
diagrams have been manually translated in the TRIO language. However, such 
translation could be made automatic by completely defining the translation rules 
mapping Rose-UML ^ TRIO'^. The construction and refinement of the PSAS initial 
TRIO specification for V&V purposes has been supported by the TRIO Editor. 

The above PSAS FT requirements have been formalized by two TRIO classes, 
namely PSAS and PSAS_Stable_Memory. The class PSAS is characterized by the TI 
value cycle_time, the TD values stable_state and new_state and by the TD 
propositions begin_cycle, end_cycle and confirm_state . The PSAS cycle time is 
assigned to 3 time units by the axiom set_cycle_time. The PSAS FT behavior is 
abstractly defined by the last five axioms allowing to cyclically producing a new state 
(axioms cyclic Jbehavior, produce_new_state and maintain_new_state) which is 
considered stable under confirmation (axioms maintain _stable_s fate and 
change _stable_state). The confirmation of the new state, provided by the 
PSAS_Stable_Memory, is conditioned by its triple repetition, as expressed by the 
axiom stable_state. 



PSAS textual requirements, extracted from documentation produced by ENEL technicians 
for a call for tender, have been grouped into 4 categories labeled SR (System Requirements), 
DR (Dependability Requirements), FR (FT Requirements) and TR (Time Requirements). 

The VDM (Vienna Development Method) formal method has already adopted such approach 
by providing a new tool from IFAD called Rose- VDM** Link. It supports round trip 
engineering between UML and VDM** through an automatic bi-directional coupling of 
Rational Rose and the IFAD VDM Tools (see the IFAD WWW Page at http://www.ifad.dk). 
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class PSAS 

visible end_cycle, new_state, confirm_state; 

temporal domain integer; 

types state_values = {state0,statel,state2,state3, stated, state5, none}; 

cycle_values = 1 .. 15; 

TI Items 

values cycle_time : cycle_values; 

TD Items 

values new-state : state_values; 

stable_state : state_values; 

propositions begin_cycle; end_cycle; confirm_state; 

vars si, s2 ; state_values; 

tc : cycle_values; 

axioms 

set_cycle_time: cycle_time = 3; 

initialisation: stable_state = stateO & new_state = none & begin-cycle; 

cyclic_behaviour: Alw(all tc (cycle-time = tc — > 

(begin-cycle Dist(end_cycle & Dist(begin_cycle,l),tc)))); 
produce_new_state: Alw(all si (end_cycle & stable_state = si — > 

ex s2 (s2 <> si & Becomes(new_state = s2)))); 
maintain_new_state: Alw(new_state = none ~end_cycle); 
maintain_stable_state: Alw(all si (~confirm_state & stable_state = si 

Dlst(stable_state = si, -1))); 

change_stable_state: Alw(all si (confirm_state & new_state = si 

Becomes(stable_state = si))); 



end PSAS 



class PSAS_Stable_Memory 

visible end_cycle, new_state, confirm_state; 

temporal domain integer; 

types state_values = {state0,statel,state2,state3, stated, state5,none|; 

TD Items 

values new-state : state_values; 

propositions end_cycle; confirm_state; 

vars si, s2, s3: state_values; 

dl, d2: integer; 

axioms 

stable_state: Alw(confirm_state all si, s2, s3, distl, dist2 

(Becomes(new_state = si) & 
NextTlme(Becomes(new_state = s2) & 
NextTlme(Becomes(new_state = s3),d2),dl) & 
si = s2 & s2 = s3)) 

end PSAS_Stable_Memory 



5. TRIO-Based Support to FT V&V 

Formal specifications may be analyzed by different Verification and Validation 
(V&V) techniques. Several formal V&V techniques have been developed 
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characterized by different degrees of formality [DondOO]. By applying formal V&V 
techniques for analysing FT properties of dependable systems we may distinguish two 
main levels of formal support, namely static analysis (level A) and dynamic analysis 
(level B). 

The static analysis of a FT specification allows the extraction of distinct views of the 
FT static model captured by the FT formalization. Static analysis may be referred 
either to the whole system or to specific functions/components. The following ones 
are some examples of static analysis: 

• analysis of relevant fault/error classes 

• analysis of FEF chains 

• analysis of the defined FT strategy, e.g. fault/error classes (not) addressed, masked 
fault classes, contained fault classes, detected error classes, isolated error classes, 
recovered error classes, handled failure classes. 

The dynamic analysis of a FT specification implies a detailed analysis of FT 
behaviours, sometimes requiring the formal specification to be refined and enriched 
with related functional requirements. Examples of dynamic types of analysis are: 

• ET consistency analysis (satisfiability proofs), e.g. generation of system behaviors 
and check of the absence of contradictions in the FT specification 

• FT adequacy analysis (truth/false proofs) checking specific FT conditions 

• proof of system FT properties 

• automatic generation of fault injection cases for the conformance testing of the 
final system. 

By considering the PSAS system the following analysis could be addressed: 

A1 Which fault classes are associated to which system components? 

A2 Which system functions are affected by corrupted-communication errors? 

A3 Which are the FT steps addressing PSAS permanent faults? 

B 1 Find PSAS histories stabilizing a new state. 

B2 Find PSAS histories which revoke a new unstable state. 

The TRIO method is endowed with tools supporting three basic V&V techniques, 
i.e. model generation, property poof and test case generation*^, which are suitable for 
performing both levels of FT analysis. In order to perform V&V activities, the 
following proof settings must be provided to the TRIO tool: 

a) load of the formal specification 

b) selection of the axiom set to be considered 

c) selection of the V&V technique to be applied 

d) selection of the Temporal Domain and the Evaluation Instant. 

Let us consider the case B1 and assume that the following values are given to the 
required settings above: 

a) TRIO classes PSAS and PSAS_Stable_Memory reported in section 4 

b) all axioms 

c) model generation 

d) Temporal Domain = 1 .. 12; Evaluation Time = 1. 

The TRIO tool builds all possible histories satisfying the chosen set of axioms, i.e. 
sequences of time dependent literals (positive and negative items) located on the time 



*^ In particular such techniques are supported by a new version of TRIO, which will be 
available at the end of the FAST Esprit project No. 25581, integrating the TRIO model 
generation within the NP-tools, by Prover Technology. 
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axis. The output of the model generation process is a graph representing for each 
relevant item its truth-value on the temporal domain. A tabular version of the B1 
results are visualized below, where at each time instant only positive items are given. 



Time 

Domain 


1= Model 


1 


begin_cycle, stable_state = stateO, new_state = none 


2 


stable_state = stateO, new_state = none 


3 


stable_state = stateO, new_state = none 


4 


end_cycle, new_state = statel, stable_state = stateO 


5 


begin_cycle, stable_state = stateO, new_state = none 


6 


stable_state = stateO, new_state = none 


7 


stable_state = stateO, new_state = none 


8 


end_cycle, new_state = statel, stable_state = stateO 


9 


begin_cycle, stable_state = stateO, new_state = none 


10 


stable_state = stateO, new_state = none 


11 


stable_state = stateO, new_state = none 


12 


end_cycle, new_state = statel, stable_state = statel 



6. Conclusions and Future Usage 

The paper has presented a methodological approach to the specification and analysis 
of high level fault tolerance requirements, which makes use of two general purpose 
methods, namely UML and TRIO. 

A main global result of the methodology is the systematization of FT concepts and 
their relations aimed at defining articulated FT strategies, eventually focussed on 
specific system components and/or functions. On one side, the UML-based support 
represents an easy way to collect and organize FT requirements. On the other side the 
TRIO-based support provides formal techniques to validate the specification of such 
requirements. 

The experimentation of the methodological approach to the ENEL PSAS system has 
allowed assessing the original textual requirements, which are now traceable on both 
(UML and TRIO) model items. 

The methodological scheme will be experienced by ENEL within the TIRAN project 
itself over the PSAS pilot application. An evaluation of this experience will be 
provided, together with the methodology itself, to the future users of the TIRAN 
framework. It will represent a guided support for the specification and analysis of ET 
requirements as well as for framework configuration and verification. 
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Abstract. With the advent of comprehensive safety standards for soft- 
ware intensive safety related systems, such as lEC 61508 and its speciali- 
sations for particular industry sectors (medical, machinery, process, etc), 
there is a need to establish combinations of techniques which can be used 
by industry to demonstrate conformance to these standards for particular 
developments. In this paper we describe one such combination of tech- 
niques, involving statecharts and B, which is aimed at reactive control 
system development. 

We define strategies for controller decomposition which allow safety in- 
variants to be distributed into subcontroller requirements, and define 
techniques for the automatic synthesis of controllers from invariants. A 
case study of a train control system is used to illustrate the ideas. 
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3.2 Structured Reactive System (SRS) Statechart Notation 
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5 Case Study: Train Control System 
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Fig. 3. 
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MACHINE Coordinator 
SEES TrainTypes 
INCLUDES SwOn, SwOff 
VARIABLES swstate 
INVARIANT swstate € State A 

{swstate = on A dstate = locked => mstate = on) A 
(swstate = off mstate = off) A 

(dbstate = on A swstate = off A motstate = stationary => 

dstate e { open, opening }) A 
(swstate = on dstate € { closing, closed, locked }) 

INITIALISATION swstate := off 
OPERATIONS 

start_train = 

PRE swstate = off 
THEN 

swstate := on || 
init_swon 



END; 



elosc-completed = 

PRE dstate = elosing 
THEN 

IF swstate = on 
THEN swon-closc-completed 
ELSE swoff -elosc-Completed 
END 

END; 



END 
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MACHINE Coordinator 

SEES TrainTypes, BooCTYPE 

INCLUDES MBController, DoorController 

VARIABLES swstate 

INVARIANT swstate € State A 

swstate = mb_swstate A swstate = d_swstate A 
{dstate yf loeked ^ mstate = off A bstate = on) A 
{swstate = on A dstate = locked ^ mstate = on) 

INITIALISATION 

swstate := off 
OPERATIONS 

start_train = 

PRE swstate = off 
THEN 

swstate := on || 
mb-start-train \ \ 
d_start_train 
END; 

stop_train = 

PRE swstate = on 
THEN 

swstate := off || 
mb-stop-train \ \ 
d-Stop-train 
END; 

open-door = 

PRE dbstate = off 
THEN 

d-open-door || 
mb_open_door 
END; 



END 
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B C { 

{ } 
} 




ClassDef(S-Ident.Name) := self 



@setlocal: 

stdout := "Class ” + classident.Name + " 
ReturnPoint := self 
@Teturnpoint: 
stdout := ”} ” 
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6 Gem-Mex: The Development Environment for 
Montages 
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SubclassDefinition ::= ’’subclass” Ident ”of” Ident ”{” 
{ Attribute } 




ClassDef(Sl-Ident.Name) := self 



©setlocal: 

stdout := ’’Class ” + classident.Name + ” {” 
ReturnPoint := self 
©returnpoint: 
stdout := ”}” 



Fig. 5. h 



X 1 



i iz g hi i 
V i w 

h i 

i 

h g X g 

i h g g 

h g i i i gg 

h vi h i g g 

i h i g g 

i i vi 

i h w i ig 



g 1 



hi g g 

X g 

vi iz h 
i V 



1 1 
g w i 

i 

h ggi g 



6.1 Generation of Language Interpreters 



i g hi g h 

h X g 

h X 



i i i giv 

i h 

whi h 



h 

i 



g g 



g 

h 

hi 



22 



u 



i s 



class Rectangle { 

xO:Int; yO:Int; xl:Int; yl : Int ; 

}; 

subclass Square of Rectangle { 
length : Int ; 

>; 

subclass Trapezium of Rectangle { 
angle : Float ; 

>; 



Class Rectangle { 


Attr 


{xO : Int} 


Attr 


•[yO : Int} 


Attr 


{xl : Int} 


Attr 


{yl : Int} 


} 


Class Square ■[ 


Attr 


{length: Int} 


Attr 


{xO : Int} 


Attr 


{yO : Int} 


Attr 


{xl : Int} 


Attr 


{yl : Int} 


} 


Class Trapezium { 


Attr 


{angle: Float} 


Attr 


{xO : Int} 


Attr 


{yO : Int} 


Attr 


{xl : Int} 


Attr 


{yl : Int} 


} 



Fig. 6. 



igh h 



g g 

h 

- h 



fl g i 



g g 
i g 

X i 



g 1 g X 
g 



1 g X 

i 



h 

vi 



g 

i 



i i g h g g 

h 

i h vi 

iz i i 
V i h 

i g h 

h X 

w h 

g wi h i i 



i w h 



1 

i g 



1 

h i g 

iz i whi h i 

i i i hi 

vi h h i i i 

w i h h g hi 

iz i 



6.2 Generation of Visnal Programming Environments 



vi 



g 



g g i h 

g i g vi h g 

i g g g i hi i 

i whi h 



X i 



vi i g g 
h g 



g 

iz i h 

i ggi g 

X 



is u is i V i 



iz i si 
s ifi 



s 



s 



s 



u 



1 






ifi us 



i g h 



1 



vi h i 
iz i 



g h i i 
i g h 
h ggi g 



1 



h g / 

i i g 
i h vi 

h X i 



VI iz 1 



ig 

X 

w i i h 

i g 

i i i 

h 

iz i 



X 1 
h w X 



1 1 1 
vi iz h X 



Wl X 1 

i i 



ig 

i CT i i 
i i 



h g hi i i 

h igh h i h wi w h 

i g i g g g i i 

igh i i h 

X high igh i 

V i i 

X h h g h V 

wi g w i 

h i i 



igh X 



X 

iv 



g 

i g i i i 

g hi i i 

h 

h g g 

h 

V h 



VI iz 

wi w X i 
X i 



Wl g 



w w h w i i i h vi w 



h w h 
h 



i hi i 



1 1 1 



i i h 



1 ^ 



view source code [] 



add term. 



write graph 



slow motion. 



step 84 







[Class Rectangle 
bUiIntj vOsIn 


■<1 , 

i? xlrlntf Vl:Int^J 


subclass Square 
length: Int ? 


of Rectangle ( 


Isubclass Trapez of Rectangle (1 


Icttigle: Float ? 1 
& 



Fig. 7. hi 



i i i h 



X 



6.3 Generation of Documentation Frames 



h 



h 



X g 

i h g g 

g g i i 



h 

g 



h 

i 




2 

_ A 


is u 

i 


h 


g 


h g 


h 


i 


iz 


h 


i i 




g i hi 


g 

— V i h 


X 

g g 


i i 


w 


w h i 


i 


i V i 


i 


i 







7 


Conclusion 


















h 


i 




i 




i 


i 


i 




i 


i g 


i 






i g 




h 




zi 


g hi 




i g i 








i 






i g 








h i 


fl xi i i 






i i 


i 


i 


g 


g g 






hi 


h 






vi 


g 


X 


i 




zi g i 


i g 






hi h i 


i 


V 


w 


i 


h 




i h 






i 


h 








X i 


g 


i 


i 


g g g i h 










i 


i 






hi 




w 






iv 


h i 




i 






i 




i 


h 






h i 




X i 




i 


h 


h 






i i 


g 


i 


g g 


g 


i 


i g 


h 


g 




h 




















X i 


i 






w g i 


i 


i 


g g 


g 






h 


h V 




V 




V 










i 


i 






V 


h 




w hi h 






i 




i 


i g 




i 




i 




i i g 


ivi 






i 






i 




h 


i 


X h g h 








i 




hi 




i 




h 




i vi 


i 




g / 




X i 


i 


i 


i hi g h 


V 


h 




ig i g 


g 




i g i 




h 






igi 






g 


giv 


X 






i 


g 


i g 




g g 


X 




h i 


g 






i 


h 


i 




i 






i 


g 




i 






i 




i 


X 






h 


i 






whi 




i i 






h g 




g 


i 


h 


hi 




g 


i h 


i g 


h 




g 




i g 




















h V 




h 




h h w h g 




g 


hi 


vi 






igi 




ig 


ggi g 


i 


i 


g h 


i 


i 






g i g 




g 


g 


W V 




vi 


izi 


g h 




i 




i w 


w 




ig w 


whi h 




i 


h 


g 




h 


ix 






i 


i i g 


X 




h 




h 


g 




ix i i 






i i i iz iv 






h 








i 










g g i 


i i 








g 










i 


g 


i h 










i 








g 










i 


ig 


i 




i 


h 


i 


i 






V i w 


h 


w 




i 


i h i 




i 


i 


h 






V i i 




h 




i h 


g i 




h 




i 


g 






g h 


wi 


h h 




i i 










si i 


- 


ifi 


u 


s 


25 


i i 


whi 


h 


g 


g 


g h 


wi h 


h 


i i 
















i 


i i 


w 


i g 






h i 


h 


X h 


wi h i 


i 




hi 








i i 


h 


wi h 


h 






i g 




i i g g 


i X i 


wi h hi 


i 


i 




h 


V 


h w h h 


vi 


i 


g 


w 




i 




i i 


i h 


i 






i i g 




iv 


hi i i 


h 


iz i 






i 


i 





References 






















u 














u 


i 


i 




i 


i 






i 


s 


i 


i 




s i 




X i 




us 


i i 


i 


s 




su i 




u i i 


2 


u 




u 




i 


i 




s 


s 


V 




vi 


s 






s 


i 




i 










y 














s 


si u i 




s 




7 


i 
















u 




u 




i 


i 






fi 


s i 




s 








i 






y 








u 






u 


i 






i 


_ 


X 




http: //www. 


first 


. gmd . de/ ~ma/ gem/ 




7 








5 


u 






ii ii 




i 


u 


s 


si 


i s 






















y 




s 






i 




us 




i i 


i 


u i i i 




i 






s 75 














7 






u 


vi 


s 


z 


i 




ifi 


i i 




ss 






i 


i 






s 




i 




i 




s 








s 


50 


_ 












u 






i 


u 




fi i i 




i s 


V 






V s- ss i 






y 








i 






















i i 


i 






i i s 






y u 


0 


i i 


0 


s 








i u i 


s 




usi 




u 




V 








i ssi 


s 




i 


i 


s 




Qth 






y 






















u 


0 i 






s 70 


is 






i 








U V 












2 


u vi 




i 










u s i 




i 




y 














s 57 




ss 




u vi 




V vi 


s 


i 


i 


ui 




i 












s 






X iv 


si 


ss 5 




2 




i s 


u 




















u 


vi 




u 


i s 




i s 






i 


u 








i 




ii i 






i i 




i 


i s 












V u 


702 




s 


27 


0 i 




5 


u 


i s 


s 






i s 


















s u 


i 


u 


s 














u 




i 


s 


i 


s 




i 




u 


i 








ii i 




7 














7 


u 






i 


i 




s s 


ifi i 


s 


is i 


i 




u 


s 














5 


7 








u 






iz 




i 




i 




i -s ifi 




u 


si 


i 


i 


s 


i 
















us 


u 


i 


i 


i V 




i 




2 s 


u 








2 


0 
















20 


- 


i 






i 


s sz 


i 


i i 




- V 


i 






- 


s s 


s 


s 








u 


i 




2 


- 


i 






i s 


sz 




s s i 


s 


u 














i s 
















s 


25 


i 


















22 


ii 


ii 


s 


s 




i s 




si i 




i u 


s s 








y 


















2 










i s 






i 




u 






i 














s 




X 


iv si 




ss 


5 






















Analysing UML Active Classes and Associated 
State Machines - 
A Lightweight Formal Approach* 



^ DISI, Universita di Genova - Italy 
^ LIPN, Institut Galilee - Universite Paris XIII, France 
® Department of Gomputer Science, Dresden University of Technology - Germany 



Abstract. We propose a precise definition of UML active classes through 
associated labelled transition systems using the algebraic specihcation 
language Casl. We are convinced that the first step to make UML pre- 
cise is to find an underlying formal model for the systems modelled by 
UML, and we argue that labelled transition systems are a sensible choice. 
This modelization will help understanding the UML constructs and will 
improve their use in practice. One of our aims is, in the future, to use 
the powerful animation and verification tools available for algebraic spec- 
ifications with UML specifications. We simplify the problem of the ap- 
plicability of our semantics by restricting the state machine constructs 
considered. This restriction does not, however, narrow the UML subset 
in study because the restricted constructs can be replaced by equiva- 
lent combinations of other constructs. Because of some ambiguities in 
the UML official semantics, we discuss the several options at hand and 
choose, for each ambiguous case, the semantics that either makes more 
sense or that allows to simplify the problem the most. 
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Integrated with the formalization of the other fragments of UML 
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^ Following UML terminology state machine is the abstract name of the construct, 
whereas state chart is the name of the corresponding diagram; here we always use 
the former. 
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3 Modelling Active Objects with Labelled Transition 
Systems 
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It is possible to define state machine semantics by allowing the run-to- 
completion steps to be applied concurrently to the orthogonal regions of a 
composite state, rather than to the whole state machine. This would allow 
the event serialization constraint to be relaxed. However, such semantics 
are quite subtle and difficult to implement. Therefore, the dynamic se- 
mantics defined in this document are based on the premise that a single 
run-to- completion step applies to the entire state machine and includes 
the concurrent steps taken by concurrent regions in the active state con- 
figuration. 
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A concurrent transition may have multiple source states and target states. 

It represents a synchronization and/or a splitting of control into concur- 
rent threads without concurrent substates. 

2 0 



An event instance can arrive at a state machine that is blocked in the 
middle of a run-to- completion step from some other object within the 
same thread, in a circular fashion. This event instance can be treated 
by orthogonal components of the state machine that are not frozen along 
transitions at that time. 
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3.3 Determining the Granularity of the i- Transitions 
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Fig. 1. 
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3.5 Determining the £-States 
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spec L-State = 

Ident and Configuration and Attributes and Event.Queue and History 

then free types 

State Ident: Configuration, Attributes, History, Event_Queue 
Ident : terminated 
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spec Event_Queue = 

Set[Event] then 
sort Event-Queue 

preds no-dispatchable-event : Event-Queue 
%% checks whether there is no dispatchable event 
__ : Event Event-Queue 

%% checks whether a given event in the queue may be selected for dispatching 
ops put : Bag[Event] Event-Queue Event-Queue 
%% adds some events to the queue 

remove : Event Event-Queue Event-Queue 
%% removes an event from the queue 
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Exec id, attrs, conf conf i , attrs i , out-cvs, loc-cvs m j id 

conf conf i 

attrs 1 out-cvs 

loc-cvs 

frozen{conf) Exec{id, attrs, conf) = conf i , attrs i , out_evs, loc-cvs 

{in_evs,t,out_evs) , ^ , 

ta: conj,attrs,tiistorye_queue id: attrs i , conf i, history i, enqueue i 



C-queuei = Receive_Events(e_gttette, in_evs loc-cvs, attrs, history, t) 
history 1 = activC-States{conf) , attrs, , t & history 



Receiving Some Events 
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Being Destroyed 
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3.7 Constraints 
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A constraint is a semantic condition or restriction expressed in text. In 
the metamodel, a Constraint is a BooleanExpression on an associated 
ModelElement(s) which must be true for the model to he well formed. 

. . . Note that a Constraint is an assertion, not an executable mechanism. 

It indicates a restriction that must be enforced by correct design of a 
system. 
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4 Auxiliary Functions 

Receive_Events : Event-Queue X Set[Event] X Attributes X History X 
Time — > Event-Queue 

Recew/e-Events e-queue, evs, attrs, history, t e-queue im e-queue i 

e-queue 

m evs m 

t history TimeOccur 
attrs history ChangeOccur 
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5 Conclusions and Related Work 
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Abstract. In this paper Software Development (SD) is understood explicitly as 
a learning process, which relies much more on induction than deduction, with 
the main goal of being predictive to requirements evolution. Concretely, 
classical processes from philosophy of science and machine learning such as 
hypothesis generation, refinement, confirmation and revision have their 
counterpart in requirement engineering, program construction, validation and 
modification in SD, respectively. Consequently, we have investigated the 
appropriateness for software modelling of the most important paradigms of 
modelling selection in machine learning. Under the notion of incremental 
learning, we introduce a new factor, predictiveness, as the ability to foresee 
future changes in the specification, thereby reducing the number of revisions. 
As a result, other quality factors are revised. Finally, a predictive software life 
cycle is outlined as an incremental learning session, which may or may not be 
automated. 



1 Introduction 

Software engineering was considered a pure science just two or three decades ago. 
Theoretical and formal methods were prevalent. Nowadays, we have a much more 
realistic conception of software engineering as an experimental science [6] . Empirical 
studies of real problems are encouraged and their conclusions are usually much more 
successful in practice than theoretical results. Moreover, many times theoretical 
studies are not applicable because in the end they do not model the software 
construction process. 

In our opinion, the formal methods in software engineering cannot be fully 
exploited due to still frequent conceptions of software as being “from specification to 
final product”. This does not take maintenance nor the generation of that specification 
into account. 

Fortunately, there is an increasing interest in requirements elicitation and evolution 
as the most important topics in software engineering. Requirements Engineering has 
made some important things patently clear: the need to take the context of a computer 
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system into consideration, i.e., “the real-world environment in which the system 
operates, including the social structure and the people therein’ and the fact “that 
requirements are always incomplete; each stage involves identifying new 
requirements based on experiences from previous stages. . . and requirements and 
design affect each other” [8]. 

The other two fundamental (and more classical) areas of research for improving 
the economics of software have been reusability and modifiability, the latter being 
more relevant when a particular system is already implemented. The maintenance 
cost is greatly reduced by improving the modifiability and/or extensibility software 
quality factors. Another neglected but fundamental question is whether we are able to 
reduce the modification probability. The idea is to ‘predict’ requirement evolution as 
much as possible, in order to minimise the remaking of software as a trace of this 
evolution. In order to gain greater benefits, this “predictive model of requirements” 
should be made upon previous models by reusing parts of other specifications and 
taking context into account. 

It should be explicitly stated that this predictive character of the model must be 
preserved during the remainder of the life-cycle: the design must be conceived to 
maintain the generality of the model, validation must be made according to this 
general model, and, more importantly, future modifications must consist of coherent 
revisions, not extensional ‘patches’ to the model. 

With the appearance of new approaches, such as adaptive software [28] or 
intelligent software [30], which include techniques and languages for further 
generalisation, an empirical and theoretical study of when a generalisation of the 
model is useful and how it should be done seems necessary. The flippancy here 
would be to start from scratch or to reinvent the wheel. As we will see in the 
following sections, predictive modelling in particular and philosophy of science in 
general historically been able to provide us very useful terminology and tools to 
select the most likely or the most informative model. 

This paper tries to emphasise the benefits of adapting the paradigm of theory 
construction to software, and to recognise and situate the role of induction in software 
engineering. In fact, recent popular subjects in the field such as adaptive software or 
intelligent software are in essence inductive. However, none of them use inductive 
tools and techniques in an explicit way. 

Induction, as we use throughout this paper, is the process of theory abstraction 
from facts. Karl Popper proposed [36] the concept of verisimilitude as the level of 
agreement with the facts. Since there are an infinite number of theories which cover a 
finite number of examples, the question of verisimilitude must be contrasted with all 
the possible future examples that may appear in a given context. The quandary of 
whether there is any way to know, a priori, if a given hypothesis will be followed by 
future experiences in that context is obvious. If we know the initial distribution of 
hypotheses in that context, the plausibility of the hypothesis can be obtained in a 
Bayesian way. Since this initial distribution is generally unknown, many different 
measures of the quality of theories have been proposed in philosophy of science and 
Machine Learning (ML), generally in an informal way. From these, there are two 
main trends ([39]): descriptional induction ([5]), which is usually related to the 
simplicity criterion (or Occam’s Razor) and the view of learning as compression; and 
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explanatory induction ([39]), which is more closely related to coherence, cohesion or 
‘consilience’ criteria ([41]). 

In 1978, Rissanen formalised Occam’s Razor under the Minimum Description 
Length (MDL) principle, quickly spreading over the theory and practice of ML and 
predictive modelling. In his later formulation ([5]), the MDL principle advocates that 
the best description of a given data is the shortest one. Apart from all the 
methodological advantages of simplicity, the major reason for using the MDL 
principle is that it usually avoids over-specialisation (underfitting) and over- 
generalisation (overfitting). From here it is usually argued that “the shorter the 
hypothesis the more predictable it is”. On the contrary, ‘consilience’ or coherence 
refer to the idea that the data must be covered by the same general rule. Thagard 
([41]) postulated that “explanatory coherence” is more important for durability than 
prediction and confirmation: “a hypothesis exhibits explanatory coherence with 

another if it is explained by the other, explains the other, is used with the other in 
explaining other propositions, or if both participate in analogous explanations” . 
Another related notion is that of intensionality ([19]), which is based on the avoidance 
of extensional patches to the theory. 

The convenience of both these trends will be studied for the case of software, in 
order to obtain predictive and coherent models for the requirements which will 
improve software quality factors. In the ML literature [31], there is a classical 
paradigm that is necessary for problems of medium or large complexity: incremental 
learning. The evidence is obtained incrementally and new evidence can appear which 
may force the revision of the model. Revision is then the most important process in 
incremental learning and is motivated by two kinds of errors: anomalies (cases which 
are not explained by the current theory) and novelties (new cases which are not 
covered). The incremental paradigm is the most appropriate one for software. 

The paper is organised as follows. In Section 2 we introduce an analogy between 
software development and theory induction, which we contrast with previous (and 
very debated) analogies between software development and deduction and 
mathematics. 

Section 3 reviews many software quality factors under the inductive paradigm. A 
new quality factor, ‘predictiveness’, is defined and is related to other software quality 
factors such as functionality, validation, reusability, modifiability, . . . 

Section 4 introduces a new life-cycle as an incremental learning session which 
attempts to reduce prediction errors. The automation is discussed, as applied to 
declarative programming (logic programming), because the techniques and stages 
required for the new life-cycle (ILP, evaluation, transformation, revision, etc.) are 
much more mature than in any other paradigm. 

Finally, Section 5 concludes the paper with a discussion of the practical relevance 
of this work and future directions. 



2 Programs as Scientific Theories 

The statement “programs are scientific theories” or, alternatively, “software is a 
learning process” summarises the main idea developed in this section. Before 
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presenting this analogy, we will review the most well-known analogies in order to 
understand software development. In our opinion, these analogies have failed to 
capture the essence of software, although partial mappings have been useful. 

2.1 Existing Analogies 

The use of analogies with pure mathematics to formalise the processes of computer 
programming was greatly influenced and promoted by the seminal paper from Hoare 
[24]. This first analogy, known as “Verifiers’ Analogy”, established that proofs are to 
theorems as verifications are to programs: 

Verifiers’ Analogy 

Mathematics Programming 

theorem program 

proof verification 

After the first successes of some simple programs of algorithmic nature, the debate 
began precisely from the side of mathematics, exemplarised by the influential paper 
by De Millo, Lipton and Perils [13]. The preceding analogy was criticised and 
replaced by the following one, which is based on the idea that programs are formal 
whereas the requirements for a program are informal: 

De Millo-Lipton-Perlis Analogy 
Mathematics Programming 



theorem 




specification 


proof 




program 


imaginary formal demonstration 




verification 



The new trends in automated programming, popularised by the logic programming 
community, were very difficult to conciliate with an analogy with mathematics as a 
social science. Thus, the analogy was revised once again [38]: 

Automated Programming Analogy 
Mathematics Programming 



problem 




specification 


theorem 




program 


proof 




program derivation 



However, Colburn [11] affirms that “for unless there is some sort of independent 
guarantee that the program specifications, no matter how formally rendered, actually 
specify a program which solves the problem, one must run the program to determine 
whether the solution design embodied by the specification is correct”. In this way, he 
postulates that software is the final test for validating the specification. 
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Finally, Fetzer reopened the debate and introduced an analogy between computer 
programs and scientific theories [17]: 



Fetzer’s Analogy 





Mathematical Proofs 


Scientific Theories 


Computer Programs 


Syntactic Entities: 


Yes 


Yes 


Yes 


Semantic Significance: 


No 


Yes 


Yes 


Causal Capability: 


No 


No 


Yes 



In our opinion, the difference between scientific theories and programs in causal 
capability disappears if we consider software to be a learning process (which shares 
the same paradigm with philosophy of science but has causal capability), where the 
learned theory (the program) can be used to interact with the environment. 

2.2 Scientific Theories and Programs 

The assumption that there is an “independent guarantee” that the specification is 
correct for a given problem is rather optimistic in the context of modern software 
development, where requirements and, consequently, applications are very complex. 
It is impossible to completely and definitely establish the intended behaviour that the 
system should show. 

Current methodologies end up accepting the dynamic character of requirements, 
and include loops back to each of the stages, including a loop to requirement 
elicitation. Then it is finally recognised that requirements are never completely stated, 
that they evolve and that they are related to the environment, the context of 
specifications, the ‘reality’. 

The same idea is implicitly suggested by the maxim that “testing can be used to 
show the presence of bugs, but never to show their absence” [15], although applied to 
a restricted view of software. The extended maxim “requirements cannot be fully 
validated, just invalidated” conforms perfectly with Popper’s conception of scientific 
methodology [36] where scientific hypotheses can possibly be shown to be false but 
can never be shown to be true. 

This impels us to looking for more realistic conceptions of programming. We 
propose a new analogy between scientific methodology and programming 
methodology which shows the numerous links that can be established: 

Programs as Scientific Theories Analogy 



Science 




Prog ramming 


reality 




requirements context 


problem 




problem 


experimentation data 




cases / interviews / scenarios 


construed evidence 




requirements 


evaluation 




analysis 


best hypothesis 




specification 


refinement 




transformation 


theory 




program 


verisimilitude 




correctness 


anomalies 




exceptions 
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confirmatoty experiments 




testing 


confirmation 




validation 


revision 




modification 


background knowledge 




SW. repositories 


technical books 




technical/programmer’s doc. 


science text books 




user documentation 



The difference between best hypothesis and theory in Science is less than the 
difference between specification and program in software engineering. In both cases, 
however, a hypothesis-specification is not usually predictive/operational and it must 
be refined/transformed into a more manageable and applicable form, by the use of 
mathematisation/formalisation and a proper engagement with the background 
knowledge / repositories. As we have stated, the analogy should be well understood 
by regarding programs not only as simple scientific theories which predict the outputs 
for given inputs but also as systems that interact with an environment or reality 
according to the ontology and hypotheses that have been learned, i.e., interactive 
learning systems. This ‘new’ analogy offers many equivalences to work on and many 
of the results in one field can be applied to the other. Therefore, following this 
comparison. Figure 1 shows how deduction and induction are more or less used 
depending on the stage of the development of a scientific theory or a software system. 




Fig. 1. Main stages in scientific theories and software systems development. 



It is remarkable that, in some way, the philosophy of science and software 
engineering are complementary in experience and techniques because they have 
focused primarily on different stages. 

For instance, the third and fourth stages (of a more engineering character) have 
been thoroughly addressed on the software side, especially the stage that is called 
‘transformation’, which includes design and codification. In automated programming, 






Software as Learning: Quality Factors and Life-Cycle Revised 153 

this transformation stage is the most important one, because it is not convenient to 
directly execute the specification, and it is necessary to transform it by using program 
transformation techniques and further analyses [35]. The final program evolves from 
the specification to better performance characteristics, while still preserving 
semantics. 

On the contrary, the first and second stages have been traditionally addressed by 
philosophy of science. Only recently these stages have been taken into consideration 
and they are included in the software construction paradigm under the banner of 
“requirement engineering”. However, it is not usually recognised in the literature that 
the techniques should be mainly inductive. The information transmitted from the user 
to the developer is incomplete and inexact. The developer must complete and explain 
it by inductive methods. This inference process has recently given name to a different 
approach to software engineering: inductive programming [33]. According to 
Partridge: “The science of creating software is based on deductive methods. But 
induction, deduction ’s ignored sibling, could have a profound effect on the future 
development of computer science theory and practice”. In our opinion, this effect will 
come true if both inferences can be effectively combined. 

Finally, our concern is not to present software engineering as an experimental 
science but to show that each program can be seen as a scientific theory and that each 
software problem can be seen as a learning problem. We will work under this analogy 
for the rest of the paper, mostly investigating the implications from theory formation 
and revision to program generation and modification. 

From theory formation we will translate the debate between descriptive and 
explanatory approaches to theory construction in science (see [39] for some 
contrasted positions in this debate). From theory revision (and abduction) we will try 
to identify which kind of software modifications are preferable: minimal extensional 
modifications or deeper coherent ones. 



3 A Revision of Software Quality Factors 

As we stated above, the role of the specification as a tentative hypothesis forces a 
revision of many software quality factors. The factors that are more directly related to 
the compliance with the specification are functionality, completeness, correctness, 
reliability and robustness. Other factors which are indirectly related such as 
testability, traceability, adaptability, flexibility, reusability, generality, maintainability 
/modifiability, practical modularity/granularity, ideal modularity or module 
independence, coupling, cohesion, efficiency/performance, comprehensibility and 
intelligibility will be discussed later*. 

The main factors are classically defined in terms of “the specification” or 
“requirements” ([26], [27]): 

• Functionality, the degree to which a system “satisfies stated or implied 
needs”. 



* For the factors that are not explicitly defined here, we refer to [26] and [27]. 
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• Completeness: usually assumed in functionality, it is the degree to which a 
system or component implements all required capabilities. 

• Correctness: is the fundamental part of functionality (jointly with 
completeness): the degree to which software, documentation, or other items meet 
specified requirements (classical view) or meet user needs and expectations, 
whether specified or not (modern view). 

• Reliability: “the ability of a component to perform its required functions 
under stated conditions for a specified period of time”. 

• Robustness: “the degree to which a system or component can function 
correctly in the presence of invalid inputs or stressful environmental conditions”. 

Most of them deal with “stated or implied needs”, “required capabilities”, “specified 
requirements”, “expectations, whether specified or not” and “required functions”. 
However, the question arises of what software feature measures the correctness of this 
specification or specified requirement wrt. the “stated or implied needs”. 

In our opinion, a new factor is required to measure the goodness of the 
requirement elicitation stage and the whole process of specification (hypothesis) 
revision during the overall life-cycle: 

Definition 3.1. Software Predictiveness 

Predictiveness is the degree to which the software system predicts present and 
future requirements in the context where the requirements are originated. 

The key issue is that the behaviour of a program is seen as a prediction given from the 
hypothetical specification. The analogy from incremental learning is now as follows: 
software construction is an incremental process. The new goal is not necessarily to 
achieve the highest accuracy at the end of a first prototype or version (or even with 
the ‘last’ version), but to maximise the cumulative benefits (prediction hits) obtained 
throughout the entire life of the software. 

Consequently, some concepts must be redefined. If we regard functionality 
equivalent to predictive accuracy, we must reconsider the components of 
functionality. 

Functionality or predictiveness includes: 

• correctness (prediction for normal situations), 

• robustness (prediction for environment or abnormal situations), 

• reliability (minimisation of anomalies), and 

• completeness (minimisation of novelties). 

Since a modification is required when there is a lack of functionality, modifiability 
(which includes extensibility) should cover both prediction errors (anomalies) and 
failure to predict (novelties). The former are motivated by a lack of correctness or 
reliability and the latter by a failure of robustness or completeness. 

Finally, maintainability is redefined as considering both the predictiveness and 
modifiability factors. That is to say, it weights the frequency and scope of 
modifications. For instance, a software system can be non predictive at all and highly 
modifiable, resulting in a maintainable software. Conversely, a software system can 
be not modifiable at all but, if it has been predictive for changing requirements, then 
the resulting cost of maintenance could still be low. 
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Next we deal with how the learning/science analogy for software helps to 
redefined many of these and other quality factors in a more detailed way. 

3.1 Functionality and Validation 

In the reorganisation made after the introduction of predictiveness, one may still 
question why we have included reliability inside functionality. The reason that has 
been argued is that, since the requirements are never definite, reliability depends more 
on the accuracy of the requirements elicitation than on the rest of the design and 
implementation phases. However, the relationship between these later phases and 
reliability is, at first glance, not related to the predictiveness factor. We will see that 
this is not the case, and even the later phases of the software life-cycle can be better 
understood using the analogy with a learning session. 

For example, it is widely accepted that redundancy compromises reliability 
because inconsistencies can easily arise, and checking them is sparse and 
consequently more difficult. An initial reflection would suggest that the removal of 
redundancies is the key to reliability. In [42], Gerard Wolff establishes the correlation 
between software and information compression in a direct way, arguing that “the 
process of designing well structured software may be seen as a process of information 
compression” . Although the parallel between automated programming and pattern 
recognition was recognised by Banerji in the eighties [4], Wolff reminds us that 
patterns such as iteration, function, procedure or sub-routine, and the idea of 
recursion are all forms of information compression. The same applies to object- 
oriented abstraction through the use of inheritance. 

The paradox arises when conditional statements {if. then., else and cases) are well 
justified by this approach. However, it has been recognised that the number of 
“cases” or “exceptions” in software increases the possibility of errors (and makes 
modifiability difficult). Moreover, there is a maintainability measure, known as 
cyclomatic complexity [25], which measures exactly this, the number of conditions in 
the source. 

In this way, an intensional model (with few exceptions) seems much easier to 
check. In particular, apart from reusability, object-oriented methodologies (and 
especially the polymorphism technique) improve reliability because they generally 
eliminate long cases and exceptions with a considerable increase in code length. 

As the software becomes more complex and requirements evolve during software 
validation, validation is finally applied to a whole which can be influenced by 
requirements elicitation errors, design errors or implementation errors. However, the 
idea of intensional and coherent models and structures applies to all the stages and 
must be preserved from specification to final code. 

3.2 Reusability 

The coherence and simplicity criteria are have long been known to improve 
reusability (keep in mind the claims keep methods coherent and keep methods small 
[37]). However, intensionality is more important for reusability than simplicity. For 
instance, we can make a very simple program work for a given specification or data. 
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but if we have no foresight, the software will be not useful to slight changes in the 
specification. In this case, the problem resides in selecting the ‘easy’ or ‘extensional’ 
solutions, the most specific ones instead of the most general ones. 

This avoidance of application specific procedures, methods, modules, etc, is 
directed by the following classical guidelines [37]: 

• provide uniform coverage: if input conditions can occur in various 
combinations, write methods for all combinations, not just the ones that you 
currently need. 

• broaden the method as much as possible: try to generalise argument types, 
preconditions and constraints, assumptions about how the method works, and the 
context in which the method operates. Take meaningful actions on empty values, 
extreme values, and out-of-hound values (anomalies). Often a method can be 
made more general with a slight increase in code. 

In addition, reusability is based on again taking advantage of the effort made in 
previous software components. Although there are some approaches where the reused 
parts can be modified (adapted) from project to project [12], the ideal option is to 
reuse it exactly as it was, benefiting from all the acquired validation, something that is 
guaranteed by encapsulation, restricting that the module could he modified at the 
moment of reusability. 

3.3 Modifiability 

Whatever the software system is, predictiveness cannot be complete and, 
unavoidably, prediction errors will sometimes occur. In that case a question we must 
ask ourselves is whether making predictive software, i.e., reducing modification 
frequency, entails an increase in the cost of modification, thus eventually 
compromising overall maintenance. To answer this, we would need to know what 
kind of software is most maintainable in the following way: 

• it predicts specification changes in order to reduce the number of future 
changes to software. 

• once a failure in prediction occurs, the modification can be made smoothly. 
The question is how are these two properties compatible and to what extent. 

It is well known that redundancy also compromises modifiability, but, at the same 
time, every software developer knows that excessive compression (cryptic models, 
code or documentation) also hinders modifiability. Wolff’s new concept of software 
[42] is based on compression, based on the fact that short software is more 
manageable and that the reduction of redundancy eases modifiability and 
extensibility. In the end, despite its predictive shortcomings, the MDL principle (as a 
preference for compressed models) is not valid for software development because it 
has been experimentally proved that extremely compressed models are not 
appropriate for reusability, as for other software quality factors, such as 
comprehensibility, testability and modifiability itself. 

Is there then any good compromise between compression and avoidance of 
redundancy? The answer is again to realise that avoidance of redundancy can be 
achieved without excessive compression. In other words, there are an infinite number 
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of irreduceable models (without redundancy), such as intensional models, which are 
not the most compressed models. 

The explanatory paradigm of ML and philosophy of science is the most 
appropriate one to ensure functionality, reusability, modifiability and maintenance. 
Some other factors such as traceability, modularity, cohesion, comprehensibility and 
intelligibility can also be partially redefined under the paradigm of machine learning 
or philosophy of science (especially the explanatory view). For instance, performance 
can be seen in terms of lazy vs. eager learning methods [29]. Eager learning works 
with a model, whereas lazy learning predicts each new instance by comparing it with 
old cases. In the case of software, eager learning obviously requires more effort at 
development time and revision is more complicated, but performance and reusability 
are not compromised. 

Nevertheless, from the ML experimental and theoretical results on the complexity 
of lazy methods, a medium or large size predictive system must necessarily be based 
on eager learning methods, and, in the following, we will take for granted that this is 
the case. 



4 Predictive Software Life- Cycle 

In section 2, the five main common stages between science and software were 
presented just as they are, without explicit influence between them. The analogy is 
now exploited to re-design the software life-cycle with the goal of making it 
predictive, and introducing model revision as one of the most important (and 
reiterative) stages. 

4.1 A New Life Cycle 

Figure 2 represents a mixture between an automated software construction cycle and 
scientific theory evolution. The terminology is used indistinctly, by either borrowing 
a term from philosophy of science (or ML) or by using a term from software 
engineering. 

The process begins by gathering the data and partial requirements of the problem 
and inducing a first model from these examples usually with the help of background 
knowledge which consists of reusable software components of previous projects and 
some other information about the domain of the reality from which the problem 
originates. The next stages are quite similar to the classical or automated life-cycles, 
depending on the degree of formalisation of the model and the automation of the 
transformation stage. The first result of the process is a program which can be 
contrasted / validated with more use examples or with real operation. This 
comparison may trigger a partial or whole revision of the model, which is followed 
by a rederivation of the program. 

Obviously, this cycle could be more detailed depending on the automated or non- 
automated character of each stage. For instance, in a non-automated developing 
schema, an analysis stage could be introduced between an induced partial 
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specification and the model, without using previous software. The design would 
convert this initial model into a refined model by using the repositories. 




Fig. 2. Predictive Software Ufe-Cjcle 



4.2 Towards the Automation of the Predictive Life-Cycle 

As the analogy suggests, at present, the goal would be to (partially) automate the 
process by using techniques from ML. However, automated inductive methods are 
not yet ready for most of the complex software problems we face. Nonetheless, 
specifications are getting increasingly more complex and more data-based, and ML 
techniques are becoming more powerful to justify the inductive software paradigm 
practically and economically. Partridge [33] presents some successful cases of 
automated construction of software from sample data. 

There are two generic approaches for research towards this difficult goal: 1) to 
evolve simple, fully-automated software systems into more complex systems; and 2) 
to develop semi-automated systems. Both approaches highlight a revival of 
declarative paradigms, because declarative languages are more mature for automating 
the stages of the previous life-cycle, and more intelligible. 

For the first via, logic programming is clearly the most appropriate paradigm at 
present. Inductive Logic Programming (ILP) [32] represents the automation of the 
stage of generation and selection from examples and background knowledge. The 
automation of the transformation stage is ensured by many years of research in 
transformation techniques (see e.g. [35]). The automation of the revision of the model 
can be found in works usually originated in non-monotonic approaches inside AI, by 
using logical theories [9] or more software specific approaches [1]. Finally, the 
application stage is performed directly through SLD-resolution or after a 
specialisation stage (see e.g. [2]) for improving performance. 
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The problems of scalability appear at all the stages, but more critically in the first 
stage. From the first recovery of specifications by using ILP [10], and after the 
application for inducing simple algorithms shown in part 111 of [7], the prospect of 
ILP for program synthesis has sometimes been discredited and biased. Nowadays, 
ILP is addressing more complex problems, so the predictive declarative programming 
paradigm can address medium-complexity problems, such as web-agents, controllers 
in changing environments, software assistants, and the like. Nonetheless, we must 
recognise the main problems of ILP for software engineering: background knowledge 
usage bottleneck and knowledge mobilisation [18]. 

For the second via, the most important issue is the intelligibility of software, i.e., if 
some part of the model (or the code) is automatically generated from the user’s 
requirements, it must be intelligible to humans, in order to ensure good coordination 
with manually generated software and allowing for manual maintenance and 
revisions. In this case, the use of declarative languages is even more justified. 



5. Conclusions and Future Work 

This paper has focused on the view of programs as scientific theories or, more 
precisely, software development as learning. This analogy forces a reconsideration of 
the quality factors of software and the software construction life-cycle. New software 
characteristics are distinguished, mainly that software must be predictive, in order to 
minimise future modifications, and other software factors are redefined. Induction 
will be more important than deduction in the future, when automation is possible for 
complex systems. 

Software systems must receive feedback from the user about the quality of its task: 
adequacy to user’s needs, efficiency, robustness, etc., and they must update to the 
user’s demands dynamically. In other words, software systems must learn from the 
environment and user’s needs, in an interactive way quite similar to query or 
interactive learning [3]. 

The recent aim for automation of induction has driven us to highlight and 
encourage the productive translations of ML techniques to software engineering. 
Although full automation is not possible at the moment, the analogy, the revision of 
factors and the new life-cycle are useful for traditionally developed software. This is 
the keypoint of the paper, to highlight that a change in attitude (or paradigm) in 
software construction can be useful in practice even without any automation at all. 

In a broader context, many historical traits of the short life of software engineering 
(in contrast to the long life of philosophy of science) can also be better understood. 
For instance, many techniques and paradigms of software engineering in the last 
decades can be seen as tools and mechanisms to ease compression while preserving 
intensionality (avoidance of exceptions), such as structured programming, object- 
oriented programming, encapsulation, polymorphism, etc. 

Moreover, the emphasis placed on the inductive phase of modelling to make 
software more predictive matches the increasing relevance that requirement elicitation 
has been acquiring in software engineering theory and practices in the last decade. 
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At present, the authors are developing inductive algorithms and systems for other 
more powerful declarative languages, for which transformation and specialisation 
techniques are also developed [35], [2]. In particular, the induction of functional logic 
programs has been attempted [20] [21] in order to allow the acceptance of more 
expressive and complex requirement cases as examples, which is usual in software 
applications. The system FLIP [16] is specially designed to induce recursive 
programs and it also supports the use of background knowledge, with the long-term 
goal of automating [22] more and more parts of the whole process. 

As future work, from a much more practical point of view, software is a very 
appropriate place to experiment new techniques from AI and ML (see e.g. [40]). 
Moreover, AI and ML can expand their commercial applications in this area. Many 
ML paradigms and techniques [31] can be used in different processes and stages of 
software construction: evaluation criteria like cross-validation, query learning [3], 
reinforcement learning applied to constructive languages [23], explanation-based 
learning, [14], data mining for knowledge-based software, analogical reasoning, case- 
based reasoning, genetic computation, etc. 

In summary, our analogy also shows that until machine intelligence (and ML) 
approaches human ability more closely, fully automated programming will remain a 
fallacy. In the meantime, in accordance with the analogy presented here and in an 
effort to reach the Utopia of “intelligent software” [30], a more prosperous 
methodology for software construction could be devised from the nascent “predictive 
software”. 
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Abstract. The problem of consistently engineering large, complex software 
systems of today is often addressed by introducing new, “improved” models. 
Examples of such models are architectural, design, structural, behavioral, and 
so forth. Each software model is intended to highlight a particular view of a de- 
sired system. A combination of multiple models is needed to represent and un- 
derstand the entire system. Ensuring that the various models used in develop- 
ment are consistent relative to each other thus becomes a critical concern. This 
paper presents an approach that integrates and ensures the consistency across an 
architectural and a number of design models. The goal of this work is to com- 
bine the respective strengths of a powerful, specialized (architecture-based) 
modeling approach with a widely used, general (design-based) approach. We 
have formally addressed the various details of our approach, which has allowed 
us to construct a large set of supporting tools to automate the related develop- 
ment activities. We use an example application throughout the paper to illus- 
trate the concepts. 



1 Introduction 

The software community places great hopes on software modeling notations and 
techniques to ease a variety of development challenges. The intellectual toolset avail- 
able to software developers has been steadily enriched with more powerful and more 
comprehensive models. At the same time, the growing number of heterogeneous 
models has resulted in an observable split within this community: one part of the 
community is working on and with special-purpose development models; another part 
focuses on general-purpose models. Special-purpose models tend to focus on individ- 
ual software development issues and are typically accompanied by powerful analyti- 
cal evaluation tools. General-purpose models, on the other hand, address a wider 
range of issues that arise during development, typically resulting in a family of mod- 
els that span and relate those issues. 

This split has impacted the two communities’ visions of how software develop- 
ment challenges are best addressed. A special-purpose approach is typically centered 
around a single design notation with a narrow modeling and analysis focus (e.g., an 
architecture description language, or ADL [14]). A general-purpose approach em- 
braces a family of design notations with a much broader, system- wide focus (e.g., the 
Unified Modeling Language, or UML [1]). Thus, for instance, UML emphasizes 

T. Maibaum (Ed.): EASE 2000, LNCS 1783, pp. 178-192, 2000. 
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modeling practicality and breadth, while ADLs tend to emphasize rigor and depth. 
Both these perspectives are needed to address the hroad spectrum of rapidly changing 
situations that arise in software development. Our previous work has demonstrated 
that the two perspectives can indeed play complementary roles in modeling and ana- 
lyzing software architectures [10,12,16]. We have recently begun using combinations 
of the general- and special-purpose approaches to aid us in the task of sound software 
refinement: refining high-level software models (i.e., architectures) into lower-level 
models (i.e., designs and implementations) in a manner that preserves the desired 
system properties and relationships [7]. 

This paper discusses the issues we have encountered in attempting to bridge the 
two perspectives and the solutions we have developed to address those issues. In 
particular, we have augmented our ADL-based approach to modeling, analysis, 
simulation, and evolution of architecturally relevant aspects of a system (e.g., system- 
level structure and interactions, performance, reliability), with the strengths of UML: 
supporting a broad range of both high- and low-level development concerns with a 
widely adopted, standard notation. 

Integrating an ADL-hased approach with UML is a non-trivial task. One difficulty 
arises from the difference in the modeling foci, language constructs, and assumptions 
between an ADL and UML. Therefore, the first critical challenge is to ensure that the 
model, as specified in the ADL, is transferred into UML as faithfully as possible, and 
vice versa. Another difficulty is a by-product of the numerous modeling notations 
within UML (component, class, object, state chart, use case, activity, etc. diagrams): 
one view of a system model, as depicted in one notation (e.g., class diagram), may be 
inconsistent with another view, as depicted in another notation (e.g., activity dia- 
gram). Thus, the second critical challenge is to ensure that changes made in one view 
are reflected as faithfully as possible in another. 

We have developed and exploited two techniques to deal with these two chal- 
lenges. They are illustrated in Figure 1. The figure depicts the relationship between 
the UML modeling constructs (“Core UML”) and the constructs of an ADL, such as 
Rapide [6] or C2 [18]. As indicated in the figure, only a certain, small number of 
ADL constructs can be represented in “Core UML”. This should come as no surprise 
since, as discussed above, ADLs are special-purpose notations that tend to favor rigor 
and formalism - concepts that are less present in UML due to its practitioner-oriented. 



Fig. 1. Extending and Augmenting UML; challenges to rep- 
resent ADL and analysis Constructs in UML. 




UML Meta-Model Extension 



general-purpose nature. 
However, UML provides a 
mechanism that allows 
“Core UML” to be ex- 
tended to address new 
modeling needs (depicted 
by the “UML Extensibility 
Mechanism” ellipse in 
Figure 1). We exploit this 
feature of UML to address 
the first challenge: sup- 
porting the transformation 
of an ADL model into a 
UML model and vice 
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versa.' The second challenge deals with ensuring the consistency across UML’s mod- 
eling notations. Since this area has not been addressed by the designers of UML, the 
strategy we pursue is to augment UML with constructs that maintain the relationships 
among the modeling elements across different notations (depicted by the “View 
Analysis Constructs” ellipse in Figure 1). In tandem, the two techniques allow us to 
specify, refine, and integrate the heterogeneous models supported by an ADL and by 
the different UML notations, alleviating the shortcomings of both languages in the 
process. 

The remainder of the paper is organized as follows. Section 2 presents our 
approach to software architecture modeling, analysis, and simulation. Section 3 
outlines our technique for transferring architectural decisions into UML. Section 4 
focuses on ensuring the consistency among UML models, both across different UML 
notations and across levels of abstraction (e.g., high-level vs. low-level design). Our 
conclusions round out the paper. 



2 Our Approach to Architecture-Based Development 

The concepts discussed in this paper are independent of the application domain, the 
specifics of the chosen architectural style, and the modeling language(s). For 
illustration purposes, we have selected the C2 architectural style [18]. C2 serves 
solely as a vehicle for exploring our ideas. It allows us to discuss the development 
issues relevant at the architectural level and motivates the discussion of transforming 
an architectural model into UML. This section also highlights certain approaches to 
software modeling and analysis that are not available in UML. 

An architecture in the C2 style consists of components, connectors (buses), and 
their configurations. Each component has two connection points, a “top” and a 
“bottom.” Components communicate solely by exchanging messages. The top 
(bottom) of a component can only be attached to the bottom (top) of one bus. It is not 
possible for components to be attached directly to each other: buses always have to 
act as intermediaries between them. However, two buses can be attached together. 

We illustrate the above concepts with an example. The architecture we use is a 
logistics system for routing incoming cargo to a set of warehouses, shown in Figure 2. 
The DelPort, Vehicle, and Warehouse components are objects that keep track of the 
states of a delivery port, a transportation vehicle, and a warehouse, respectively. Each 
may be instantiated multiple times in a system. The DelPortArt, VehicleArt, and 
WarehouseArt components are responsible for graphically depicting the states of their 
respective objects to the end-user. The CargoRouter organizes the display based on 
the actual number of port, vehicle, and warehouse instances in the system. The Clock 
provides consistent time measurement to interested components, while the 
NextShipment component determines when cargo arrives at a port, keeps track of 
available transport vehicles at each port, and tracks the cargo during its delivery to a 
warehouse. The GraphicsBinding component renders the drawing requests sent from 
the CargoRouter using a graphics toolkit, such as Java’s AWT. The five connectors 



' Note that a portion of Rapide falls outside this “extended UML” in Figure 1. This is a reflec- 
tion of the fact that UML is not always able to support all features of a given ADL [12]. 
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receive, filter, and route the messages sent by components to their appropriate 
recepients. 



1 ^ 


_ ^ 






DelPort 




Vehicle 




Warehouse 


1 


1 


1 



I 

NexlShipment 



DelPortArt 




VehicleArt 




Warehouse 

Art 



CargoRouter 

I 



Graphics 

Binding 



BindingConn 



Fig. 2. Architecture of the cargo routing system 



2.1 Architectural Analysis 

To support architecture modeling, 
analysis, implementation, and 
evolution, we have developed a 
formal type system for software 
architectures [8,11,13]. We treat 
every component specification at 
the architectural level as an 
architectural type. We distinguish 
architectural types from basic types 
(e.g., integer, boolean, string, array, 
record, etc.). A component has a 
name, a set of internal state 
variables, a set of interface 
elements, an associated behavior, 
and (possibly) an implementation. 

Each interface element has a direction indicator (provided or required), a name, a set 
of parameters, and (possibly) a result. Component behavior consists of an invariant 
and a set of operations. The invariant is used to specify properties that must be true of 
all component states. Each operation has preconditions, postconditions, and (possibly) 
a result. Like interface elements, operations can be provided or required. The 
preconditions and postconditions of required operations express the expected 
semantics for those operations. We separate the interface from the behavior, defining 
a mapping function from interface elements to operations. This function is a total 
surjection: each interface element is mapped to exactly one operation, while each 
operation implements at least one interface. An interface element can be mapped to an 
operation only if the types of its parameters are subtypes of the corresponding 
variable types in the operation, while the type of its result is a supertype of 
operation’s result type. This property directly enables a single operation to export 
multiple interfaces. 

This set of definitions allows us to formally treat two distinct development 
activities: evolution of individual components via subtyping [8] and analysis of an 
architecture for conformance among interacting components. In this paper we focus 
on the latter. The left side of Figure 3 shows the relevant definitions of interface 
parameter conformance and operation conformance.^ The right side of Figure 3 is a 
reflection of our experience that components need not always be able to fully 
interoperate in an architecture, but that mismatches should be allowed under certain 
situations (e.g., COTS reuse). The two extreme points on the spectrum of type 
conformance are: minimal type conformance, where at least one service (interface and 



The definitions are specified in Z, a language for modeling mathematical objects based on 
first order logic and set theory [17]. Z uses standard logical connectives (a, v, etc.) and 
set-theoretic operations(e , u, c, etc.). The complete formal defintion of the type system is 
given in [11]. 
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Fig. 3. Formal specification of architectural type conformance predicates 

corresponding operation) required by each component is provided by some other 
component along its communication links; and full type conformance, where every 
service required by every component is provided by some component along its 
communication links. 



2.2 Example of Architectural Analysis 

We illustrate architectural type conformance with a simple example drawn from the 
cargo routing application (recall Figure 2). Figure 4 shows partial models of the 
DelPort and DelPortArt components, specified in the C2SADEL ADL [13]. The two 
components are intended to interact in the cargo routing system (i.e., there is a 
communication path between them in the architecture via StateConn and ArtistConn). 
In the example from Figure 4, DelPortArt requires one service: unloadShipment, 
which is mapped to its operation orl. DelPort provides an operation, opl, with a 
matching interface (as required by the interface parameter conformance predicate in 
Figure 3). Thus, to establish type conformance, we must make sure that the pre- and 
postconditions of the two operations are properly related as specified in the operation 
conformance and minimal type conformance predicates in Figure 3. To do so, we 
must establish that the following relationships hold: 

• DelPortArt orl pre => DelPort opl pre 

(s i contents) true 

Since DelPort' opl does not have any preconditions, the right-hand side (RFIS) 
of the implication becomes true. Therefore the entire implication evaluates to 
true regardless of the truth value of its left-hand side (LHS). 

• DelPort opl post => DelPortArt orl post 

{{-cap = cap + ShpSize{s)) a (s 6 -cargo)) (s e -contents) 
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component DelPortComponent is { 


component DelPortArtComponent is { 


state { cap : Int; max_cap : Int; 


state { selects : \set Int; 


cargo : \set Shipment; 


UniquelD : Int \x Int -> Int; } 


ShpSize : Shipment -> Int } 


invariant { #selects \eqgreater 0; } 


invariant { cap \eqgreater 0 \and 


interface { 


cap \eqless max_cap; } 


prov ipl: selectShipment (port : Int; 


interface { 


shp : Int) ; 


prov ipl : unloadShipment ( s : Shipment); 


req irl: unloadShipment ( s : Shipment); } 


req irl : Tick ( ) ; } 


operations { 


operations { 


prov opl : { 


prov opl : { 


let pid : Int; sid : Int; 


let s : Shipment; 


post (#-selects = #selects + 1) \and 


post (-cap = cap + ShpSize (s)) 


(UniquelD (pid, sid) \in selects); } 


\and (s \in -cargo) ; } 


req orl : { 


req orl : { 


let s : Shipment; 


let time : STATE_VARIABLE ; 


contents : STATE_VARIABLE ; 


post -time = 1 + time; } } 


pre (s \not_in contents) ; 


map { 


post (s \in -contents) ; } } 


ipl -> opl (s -> s) ; 


map { 


irl -> orl 0 ; } 


ipl -> opl (port -> pid, shp -> sid) ; 


} 


irl -> orl (s -> s) ; } 

} 



Fig. 4. Partial specification of the DelPort and DelPortArt components. # denotes set cardi- 
nality; ~ denotes the value of a variable after the operation executes; STATE_VARIABLE is 
a placeholder for any basic type 



The two matching interface elements (unloadShipment) of the DelPort and 
DelPortArt components have matching parameters (s), which are mapped to the 
respective components’ operation variables (also s). DelPortArt’ s variable 
contents is of type STATE_VARIABLE, which is intended to generically describe 
the internal state of another component in a required operation.^ contents can 
be unified with the DelPort internal state variable cargo, so that the implication 
becomes 

({-cap = cap + ShpSize(s)) a (s s -cargo)) ^ (s e -cargo) 

This implication is of the form (A a B) B and is also true: an implication 
can be false only if its RHS (b) evaluates to false; however, in this case that would 
result in the LHS (A a B) also evaluating to false, making the implication true. 

We have thus established that, at the least, minimal type conformance holds in the 
architectural interaction between DelPort and DelPortArt. 



2.3 Architectural Simulation 

The example above demonstrate how an architecture can be analyzed statically for 
desired properties. Another way in which we have been able to analyze C2-style 
architectures has been through early simulations of applications, built based on the 
applications’ architectural models. To this end, we have exploited C2’s event-based 
nature: one can rapidly construct a partial implementation of an architecture that 
mainly focuses on the components’ external (asynchronous message) interfaces. For 
example, a prototype of the cargo routing application discussed above was initially 
implemented and later augmented to include a foreign-language user interface by a 
single developer in a matter of hours [2]. Our support tools also allow insertion of 
event monitors and filters to explicitly observe message traffic and assess dynamic 
properties of the architecture. Any inconsistencies in the architecture not detected by 



Eor a more formal and in-depth treatment of STATE_variable types, see [11] 
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type conformance checking, such as inconsistencies in component interaction 
protocols, are likely to manifest themselves during simulations. 



2.4 Tool Support 

The activities described in this section (architecture modeling, analysis, simulation, 
implementation, and evolution) are supported hy DRADEL, a component-hased 
development environment [13], and a light-weigt simulation and implementation 
infrastructure [9]. Three of DRADEL’ s components are particularly relevant to this 
discussion (a fourth component will be discussed in Section 3): 

• The TopologicalConstmintChecker component analyzes an architecture for 
adherence to design heuristics and architectural style rules. Currently, this 
component ensures the rules of the C2 style, but can be easily replaced with 
components enforcing other kinds of design rules. 

• The TypeChecker component implements the rules of our architectural type 
system, briefly discussed in Section 2.1. The TypeChecker automatically performs 
the conformance checks such as those shown in Section 2.2. 

• The CodeGenerator component automatically generates architecture 
implementation skeletons discussed in Section 2.3. The skeletons are generated 
based on a component’s architectural model specified in c2sadel: all message 
generation, marshalling, and unmarshalling code is produced, as is a stub for the 
component’s internal (application-specific) behavior. Component stubs are then 
completed manually. The amount of effort needed to complete a stub depends on 
the desired faithfulness of the prototype implementation to the final system and it 
can range from a few to several hundred lines of code. 



3 Refining an Architectural Model into a UML Model 

Once an architectural model is constructured and its analysis and simulation 
demonstrate the presence (or absence) of properties of interest, the model can be used 
as a basis for system design and implementation. This requires the transfer of 
information from the architectural model to a (high-level) design and subsequent 
refinement of that design. One way to effectively accomplish this task is by 
transferring the application model from an ADL to a notation better suited for 
addressing lower-level design issues. We employ UML [1] to that end. 

UML is a semi-formally defined design language with a large, extensible set of 
modeling features that span a number of modeling diagrams (see Section 1). Our 
previous work has studied in depth the relationsip between ADLs and UML 
[10,12,16]. One outcome of this research has been a set of well-defined strategies one 
could employ to meaningfully transfer an ADL model into UML. Based on this work, 
we have recently augmented the DRADEL environment discussed in Section 2.4 to 
include UMLGenerator, a component that transforms a c2SADEL specification into a 
UML model. UMLGenerator uses a set of formally defined rules that specify how 
each c2sadel construct is transformed into a corresponding (set of) UML 
construct(s). The rules make use of predefined UML constructs, as well as 
stereotypes, UML’s built-in extensibility mechanisms. Stereotypes allow the addition 




A Formal Approach to Fleterogeneous Software Modeling 



185 



of attributes to existing modeling elements (via tagged values) and the restriction of 
modeling element semantics (via constraints). The constraint portion of a stereotype 
is formally specified in UML’s Object Constraint Language (OCL) [19]. For example, 
the compositional rules of the C2 architectural style, discussed in Section 2, can be 
specified using a UML stereotype as follows. 

Stereotype C2Architecture for instances of meta class Model 

[1] A C2 architecture is made up of only C2 model elements. 

SELF . OCLTYPE . M0DELELEMENT->F0RALL (ME | ME . STEREOTYPE= C2COMPONENT OR 
ME . STEREOTYPE = C2CONNEGTOR OR ME . STEREOTYPE = C2 ATTACHOVERCOMP OR 
ME . STEREOTYPE = C2 ATTACHUMDERCOMP OR ME . STEREOTYPE = C2 ATTACHCONNCONN) 

[2] Each C2Component has at most one C2AttachConnAbove. 

Let comps=self . oclType .modelElement->select (me | me . stereotype=C2 Component) , 
COMPS - >forAll (c I c .assocEnd. association- >select (a I 

A. stereotype = C2AttachCONNABOVE) ->SIZE <= 1) 

[3] Each C2Component has at most one C2AttachConnBelow. 

Similar to the constraint above. 

[4] Each C2Component must be attached to some connector. 

Let comps=self . oclType .modelElement->select (me | me . stereotype=C2Component) , 
COMPS - >forAll (c I c. assocEnd. association->size > 0) 

[5] Each C2Connector must be attached to some connector or component. 

Let conns=self . oclType . elements -> select (e | e . stereotype=C2Connector) , 

CONNS - >forAll (c I c. assocEnd. association->size > 0) 

The above stereotype describes only one portion of C2 and is accompanied by 
other stereotypes defining C2 components and connectors, their interactions, and the 
internal makeup of individual components and connectors as specified in C2SADEL 
[13]. This complete specification of C2 concepts in terms of UML stereotypes was 
used as the basis for implementing the UMLGenerator component. Figure 5 shows a 
partial and somewhat simplified set of c2SADEL-to-UML transformation rules as 
encoded in the UMLGenerator. 



Internal Component Object — > Class 

State Variable — > Class Private Attribute 

Component Invariant Tagged Value + Class Documentation 

Provided Operation Class Operation 

Required Operation — > Class Documentation 

Operation Pre/Post Condition — > Pre/Post Condition on Class Operation 
Message Return Type Return Type on Class Operation 
Message Parameter — > Parameter (Name + Type) on Class Operation 
Architecture Configuration (explicit invocation) — > (Object) Collaboration Diagram 
Component Instance Internal Component Object Class Instance 
Connector Instance — > «Interface» Class Instance 

Component/Connector Binding — > Object Link (instance of an association) 
Component ^ «C2-Component» Class 

Internal Component Object — > «C2-Component» Class Attribute 
Component Top Interface «Interface» Class 
Component Bottom Interface — > «Interface» Class 
Outgoing Message — > «Interface» Class «out» Operation 
Incoming Message — » «Interface» Class «in» Operation 



Fig. 5. Excerpt from the mle set for transforming c2sadel into UML. «» denotes stereotypes 
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Fig. 6. Partial UML model of CargoRouter architecture (using Rational Rose^*^) 



The UML specification resulting from this transformation is stored as a Rational 
Rose™ model [15]. A portion of the Rose model for the cargo router architecture from 
Figure 2 is shown in Figure 6: it depicts the entire architecture as a UML 
collaboration diagram (left) and the attributes of and class diagram corresponding to 
the DeliveryPort component (right). This automatically generated Rose model is 
consistent with the architectural model and is used as the basis for further, possibly 
manual refinement of the architecture as discussed below. 



4 Design Refinement and Analysis 

Architectural refinement enables us to transform our C2 architecture into a (high- 
level) UML design. Since that design will likely be further refined into lower-level 
designs (and an implementation), those subsequent refinements may become incon- 
sistent with the original architecture. This is particularly likely if the refinements are 
done manually. This section will discuss how a refinement can be automated by em- 
ploying a technique that augments UML (recall Figure 1). 



4.1 View Integration Framework 

To enable automated design analysis we have devised and applied a view integration 
framework, accompanied with a set of activities and techniques for identifying mis- 
matches in an automatable fashion [3]. This approach exploits redundancy between 
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views: for instance, if view A contains information about view B, this information can 
be seen as a constraint on B. The view integration framework is used to enforce such 
constraints and, thereby, the consistency across the views. In addition to constraints 
and consistency rules, our framework also defines what information can be exchanged 
and how it can be exchanged. This is critical for automating the process of identifying 
and resolving inconsistencies since direct comparison between views is usually infea- 
sible. Our framework has three major activities: 

• Mapping identifies related pieces of information and thereby describes what in- 
formation is overlapping. Mapping is often done manually, e.g., via naming dic- 
tionaries and traceability matrices. 

• Transformation simplifies (i.e., abstracted) detailed views or generalizes specific 
views. This activity describes how information can be exchanged and results in de- 
rived modeling information. 

• Differentiation traverses the model to identify mismatches. Mapping indicates 
what information should be compared; Transformation indicates how that infor- 
mation should be compared. 

We will illustrate these con- 
cepts using the cargo router ex- 
ample. Figure 7 depicts an excerpt 
of its design in UML in the form 
of a class diagram. This design 
varies considerably from the high- 
level design we generated in Sec- 
tion 3. As the design is further 
modified, it will become increas- 
ingly difficult to see whether the 
changes are consistent with the 
original architecture, depicted in 
Figure 2. Again, note that the 
architectural and design views 
show distinct but overlapping 
information; this redundancy between the views is used in the form of constraints in 
helping to verify consistency. It has been our observation that the major challenge of 
view integration is not the actual comparison of views {Differentiation) but instead 
the Transformation and Mapping of modeling information [3]. Since Mapping tends 
to be predominantly manual, Transformation becomes the key enabling technology 
for automated view integration. We, therefore, discuss it on more detail. 




Fig. 7. Design Refinement of CargoRouter 



4.2 Transformation 

Figure 8 captures the three major dimensions of view transformation [3]. Software 
modeling views can be seen as abstract or concrete on the one hand, and generic or 
specific on the other. The abstract-concrete dimension was foreshadowed in Section 3 
where the C2 architecture was the abstract view and the generated UML model was 
the concrete view. Note that a view’s level of abstraction is relative. Thus, for in- 
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Translation 

(e.g., collaboration to 
sequence diagram) 



Abstraction 

(e.g., between 
class diagrams) 



Consolidation 
(e.g., sequence to 
state diagram) 



C2SADEL 

A 

-class*— 

/Cstate 


^ sequence ►n 
'^ collaboration 


Uclass*— 

^state 


^ sequence 
■'^collaboration / ^ 



Fig. 8. Two dimensions of views with three dimensions of view transformations. Paths a-d 
denote possible transformation paths from concrete-specific to abstract. 



stance, the derived UML model depicted in Figure 6 is concrete relative to the C2 
view but abstract relative to the class diagram in Figure 7."* 

The generic- specific dimension denotes the generality of modeling information. 
For instance, a class diagram naturally describes a general relationship between 
classes, whereas a sequence diagram describes a specific scenario. Another way of 
saying this is that constructs in general views must capture the union of all specific 
views, and that a specific view must fit within the boundaries of its respective generic 
one. The level of generality/specificity is, again, in the eye of the beholder (e.g., a 
view is more generic than some views and more specific than others). 

Having two dimensions of views implies three types of transformation axes: Ab- 
straction to capture vertical transformation. Consolidation to capture horizontal trans- 
formation, and Translation to capture transformation within a single quadrant (both 
input and output views are of the same category). We have also observed that often 
only uni-dimensions transformations can be fully automated (e.g., [4,5]) - usually 
going from concrete to abstract or from specific to generic. 

The framework depicted in Figure 8 allows us to combine simple transformation 
techniques to enable more complex transformations in support of the integration of 
c2sadel and UML. Figure 8 depicts one such complex transformation going from the 
lower right quadrant (e.g., a concrete sequence diagram) to the upper left quadrant 
(e.g., an abstract class diagram). The three paths (“a” to “c”) indicate the three alter- 
native transformation scenarios on how to get there. Path “a” first abstracts the se- 
quence diagram and then consolidates it to yield a class diagram view. Path “b” first 
consolidates and then abstracts. Path “c” consolidates, translates, and abstracts. There 
are of course other variations using additional translations. The translation step may 
seem redundant since it does not seem to put us any closer to the target quadrant. 
Nevertheless, translation can help us in circumventing a non-existing transformation 
by translating to another view that can be abstracted/consolidated or by switching to a 
more reliable abstraction/consolidation method not available within the current view. 



Note that the implementation is the most concrete view of a system. 
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Derived = {A,D} 




Fig. 9. Representation of Abstraction Transformation (multiple views and their storage) 



The right hand-side of Figure 8 depicts existing transformations our approach cur- 
rently supports (e.g., concrete class to abstract class, sequence to state, etc.). Note that 
a few arrows are double-headed, with the second head drawn in a light gray shade. 
These cases denote examples where the reverse transformation is semi-automated. 



4.3 Implication of Transformation for Consistency Checking 

Complex transformations are not just a serial execution of individual transformations. 
To enable complex transformations we also need to address the issue of how to cap- 
ture and maintain modeling information - in particular, how to handle derived mod- 
eling information [3]. Thus, transformation methods need to be integrated in order to 
avoid the two fundamental problems that may arise: 

1. Transformation Redundancy: a modeling element should be transformed at most 
once using the same transformation method, thus avoiding transformation redun- 
dancy. 

2. Multiple Derived Results: multiple transformations of a modeling element using 
different transformation methods may result in multiple results. The model must 
therefore support multiple interpretations. 

Figure 9 demonstrates both issues using relation abstraction (a method that col- 
lapses relations among multiple modeling elements into simpler relations). The bot- 
tom-most layer on the left hand-side shows an excerpt of the class diagram from Fig- 
ure 7 with four classifiers (boxes) and a number of relations (links) between them. 
The middle layer is more abstract in that the classifier aSurplus has been eliminated 
and a more abstract relation (t) has been created to replace it. The top-most layer 
further eliminates the classifier availableGoods. We now have three views. If we 
were to store the views separately, we might eventually introduce inconsistencies 
between them. For instance, any changes to the bottom view would require updates to 
all its higher-level abstractions. This would likely become unmanageable in a large- 
scale system with a large number of user-created views plus all their transformations. 
Furthermore, if we again take the bottom view and abstract aSurplus away, we are 
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duplicating both effort and storage 
since we are not aware of the previ- 
ous abstraction. The right hand-side 
of Figure 9 depicts a possible solu- 
tion for these two problems. It sug- 
gests using an n-ary relationship 
among modeling elements. The 
figures on the left are now simply 
projections of the model on the 
right. The underlying model on the 
right minimizes information dupli- 
cation. Note that UML does not 
support n-ary relationships among 
many of its modeling elements, 
partially motivating our decision to 
augment it. Revisiting Figure 1, the 
problem of how to deal with derived 
modeling elements can only be 
solved by augmenting the model. 




missing clock 
components 
and connectors 




Fig. 10. Except of Abstracted Class Diagram 



4.4 Consistency Checking 

The issues discussed in sections 4.1 and 4.2 form the foundation that allows us to 
check the relative consistency of two or more UML models. Thus, in order to ensure 
the consistency of the UML model in Figure 7 with respect to the original C2 archi- 
tecture in Figure 2 (or Figure 6) we can automatically derive the transformation paths, 
perform the actual transformations (the refinement of the C2 model and the abstrac- 
tion of the class diagram), and then compare their respective results (two class dia- 
grams at similar levels of abstraction). Figure 10 shows an excerpt of the abstraction 
from Figure 7 using a set of abstraction rules discussed in Section 4.2 and completely 
specified in [4]. We can now observe that the architecture differs from the design in 
several ways: the design does not include the Clock component or its related connec- 
tor and depicts some component interactions (e.g., DelPort to Warehouse) that are not 
defined in the architecture. 

Although it is possible that both these cases are results of deliberate design deci- 
sions, transformation has enabled us to easily compare the two views and quickly 
highlight their inconsistencies. The human designer can then either address the incon- 
sistencies or ignore them. To date, we have automated a part of our view integration 
framework in a tool called UML/ Analyzer [3]. The abstracted view depicted in Figure 
10 can be derived automatically using our tool. 



5 Conclusion 

This paper addressed architectural modeling using a specialized approach, C2, and 
showed how it can be used to complement a general-purpose modeling language, 
UML. We discussed the benefits of C2 and UML as well as the need for integrating 
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their respective strengths. The integration of C2 and UML is not a trivial undertaking 
and we introduced two techniques to enable it; constraining UML and augmenting it. 
We showed how to represent C2 in UML (Section 3) in order to illustrate constrain- 
ing UML and how to perform complex transformations and view integration (Section 
4) in order to illustrate augmenting UML. 

This paper also presented formal approaches to software development to support a 
variety of development activities (specification, analysis, and modeling). Formalism 
plays a major role during all of those activities. Formalism is also the foundation of 
automation. The benefits of automation were illustrated throughout this paper. In 
Section 2, we discussed the analytic powers of special-purpose models like C2. Using 
C2 we were able to automatically analyze static and dynamic properties of our sys- 
tem. Automation then helped us in further refining our special-purpose C2 model into 
a general-purpose UML model (Section 3). This automated refinement capability 
removed a major obstacle to model integration since no manual labor was required in 
making tools and models work together. Finally, automation supported us during 
model validation. We illustrated automated consistency checking between views and 
demonstrated this using a C2 architecture and its corresponding UML design (Sec. 4). 

To date, we have automated many of the concepts discussed in this paper and cre- 
ated two tool suites: SAAGE (Dradel-tRose) to enable architectural modeling and 
refinement; and UML/Analyzer (also integrated with Rose) to enable automated 
transformations and consistency checking. It is our long-term vision to further extend 
the automation support to other aspects of the software life cycle. 
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CLASS Instance 
VARIABLES 

origin : Declaration, 
links : Link* 

INVARIANT 

origin ^ NULL 
METHODS 

initialize (o : Declaration, 

c : Connections) : Instance 
origin := o; 

FOREACH con IN C DO 

links ADD con createLink () 
entityType () : EntityType 
origin instanceKind () 
evaluateAction (a : Action) : Boolean 



CLASS Declaration SUPERCLASS Instance 
VARIABLES 

operation : Operation*, 
connection : Connection*, 
instanceType : EntityType, 
name : Name 
INVARIANT 

name ^ NULL AND instanceType 7^ NULL 
METHODS 

addConnection (c : Connection) : Boolean 

IF SELF lookupConnection (c name ()) = NULL AND 
ruleset allowedConnection ( 

SELF instanceKind (), 
c target () instanceKind (), 
c connectionType ()) THEN 
connection ADD c; TRUE 
ELSE FALSE 

lookupConnection (n : Name) : Connection 

COLLECT c IN connection SUCHTHAT c name () = n 

instanceKind () : EntityType 

instanceType 

createlnstance () : Instance 

instanceType source () NEW (SELF, connection) 
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2.2 Relationships 
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CLASS Connection 
VARIABLES 

name : Name, 
target : Declaration, 
instanceType : ConnectionType 
INVARIANT 

target 7^ NULL AND name 7^ NULL AND 
instanceType 7^ NULL 
METHODS 

target () : Declaration 

target 

connectionType () : ConnectionType 
instanceType 
createLink () : Link 

Link NEW (self) 



CLASS Link 
VARIABLES 

origin : Connection 
value : Instance* 

INVARIANT 

origin 7^ NULL 
METHODS 

connectionType () : ConnectionType 

origin connectionType () 
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2.3 Mapping Language Entities onto Boom Classes 
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mapping ADD (EntityType NEW (CLASS, Declaration)); 
mapping ADD (EntityType NEW (OBJECT, Instcince)); 

mapping ADD (ConnectionType NEW (POINTERDECLARATION , Connection)); 
mapping ADD (LinkType NEW (POINTER, Link)); 
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(EntityType NEW (DATATYPE, Declaration)); 

(EntityType NEW (OBJECT, Instance)); 

(EntityType NEW (DATAVALUE, Tokeninstance) ) ; 
(ConnectionType NEW (ATTRIBUTE, MultiplicityConnection) ) ; 
(LinkType NEW (ATTRIBUTELINK , NumberedLink) ) ; 
(AssociationRule NEW (CLASS, DATATYPE, ATTRIBUTE)); 
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mapping ADD (EntityType NEW (ASSOCIATION, AssociationDeclaration) ) ; 
mapping ADD (ConnectionType NEW (ASSOCIATIONEND , MultiplicityConnection) ) ; 
ruleset ADD (AssociationRule NEW (ASSOCIATION, CLASS, ASSOCIATIONEND)); 
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mapping ADD (EntityType NEW (METAPACKAGE, NamespaceDeclaration) ) ; 
mapping ADD (EntityType NEW (METACLASS, MetaDeclaration) ) ; 
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mapping ADD (ConnectionType NEW (CONTENTSDECLARATION, ContentsConnection) ) ; 
mapping ADD (LinkType NEW (CONTENTS, Link)); 

ruleset ADD (AssociationRule NEW (METAPACKAGE, METACLASS, CONTENTSDECLARATION)); 
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mapping REPLACE (EntityType NEW (METACLASS, NamespaceDeclaration) ) ; 

ruleset ADD (AssociationRule NEW (METACLASS, METACLASS, CONTENTSDECLARATION) ) ; 
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mapping ADD (EntityType NEW (ASSQCIATIONCLASS , AssociationDeclaration) ) ; 
mapping ADD (EntityType NEW (LINKOBJECT, Instance)); 

ruleset ADD (AssociationRule NEW (ASSQCIATIONCLASS, DATATYPE, ATTRIBUTE)); 
ruleset ADD (AssociationRule NEW (ASSQCIATIONCLASS, CLASS, ASSOCIATIONEND) ) ; 
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Definition 1. A class invariant Ic is 1 if it holds for all existing objects of 
type C during the following points of program execution: 

— at the beginning of any method execution, except for a new object at the 
beginning of the execution of its constructor 

— at the end of any method execution. 
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previous part of the execution sequence. 
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Theorem 1 (Soundness). Let a program be given with all proof obligations 
satisfied and an execution sequence with all class invariants holding in ctq. Then 
all class invariants hold for all objects at all states Oi in the transition sequence. 
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Theorem 2 (Completeness). Let a program be given of which all executions 
satisfy at method calls the corresponding preconditions and at both calls and 
returns all class invariants. Then there exists an annotation of the program and 
the classes such that all proof obligations are fulfilled. 

11 



m y 



1 



1 11 1 

m 1 



m 1 



y m 



y m ly 



y 1 



m 1 

1 



1 

m 

y m 



y m 



6 Conclusion 



1 1 



1 y 



m 1 




n n n 1 n n 

iiy y y 

1 

1 m 1 V 

1 m 1 



References 

n n A Logic of Object-Oriented Programs 

n n 

n n A Parallel Object-Oriented 

Language: Design and semantic foundations n 

n 1 n In The Java programming language, 2nd ed. 

n 1 

n 1 Verification of seguential and concur- 
rent programs n 1 

Reasoning about dynamically evolving process struc- 
tures: A proof theory for the parallel objeet- oriented language POOL 
n 

n 1 n n Reasoning about 

Classes in Object-Oriented Languages: Logical Models Tools n 

n 1 

An axiomatic basis for computer programming 

n n 

nk Upgrading the pre- and postcondition technique 
n 1 In 

n 1 

n n Toward Reliable Modular Programs 

Inn n 1 n 

k n n A behavioral notion of subtyping 

nn n n 1 The Temporal Logic of Reactive and Con- 
eurrent Systems n 1 

Objeet- Oriented Software Construction n 11 

n "11 Logical foundations for typed 

object-oriented languages n n 

n n n 

Specification and verification of object-oriented 
programs In n n 

k Component software : Beyond object-oriented program- 
ming n 1 



1 

ly y 1 



1 



The Object Constraint Language 



n 




Verification of Object-Z Specifications by Using 
Transition Systems: Application to the 
Radiomobile Network Design Problem 



Pablo Gruer, Vincent Hilaire, and Abder Koukam 

Universite de Technologie de Belfort Montbeliard 
4 me du chateau 
90010 Belfort Cedex, FRANCE 
Pablo . GruerSutbm . f r 



Abstract. This paper presents a technique for verifying specifications 
which uses the object-oriented state-based language Object-Z. The tech- 
nique is based upon translation of Object-Z specifications into transition 
systems. The translation of Object-Z into a transition system allows one 
to use established techniques and tools in order to verify the specihca- 
tions. We present the basis of our translation approach and then illustrate 
it by a case study. The case study consists in proving properties of our 
antennae parameter setting problem specification. 



1 Introduction 

Formal specification must fulfill two roles. The first is to provide the underlying 
rationale for the system under development. The second is to guide subsequent 
design and implementation phases. For example, the model checking approach 
may be very useful in order to verify a formula related to the specification. Fur- 
thermore this verification can be carried out automatically using model checking 
tools. While most specification formalisms are suited for the first role, few enable 
automatic verification of systems properties. 

Among specification formalisms, Z [7] has received considerable attention. Fur- 
thermore, there exist object oriented extensions of this formalism, such as Object- 
Z [1], which allow for class structured specifications. These formalisms are well 
suited for concise and comprehensible description of software but automatic anal- 
ysis tools are very rare, and often restrict to syntactic checking. 

Our approach consists in translating an Object specification towards a transi- 
tion system. Transition systems are behavioral models of software systems which 
can provide an operational semantic to specifications. Moreover, with transition 
systems, one can use established techniques [5] and tools, such as STeP [4], in 
order to prove some properties of Object-Z specifications. Nevertheless, defining 
an operational semantics for Object-Z is a difficult task. The richness of the 
specification language, that benefits from the first order predicate notation, is 
one of the reasons of the difficulty. For instance, operations described by quanti- 
fied predicates often produce a set of transitions rather than a single transition. 
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Yet, the set of transitions represents an atomic operation and, in order for the 
semantic to be correct, this atomicity must be preserved in some fashion. 

This paper presents a verification technique based on translation rules of Object- 
Z specifications into transition systems. Rather than an exhaustive presentation 
of the transformation rules, we address some difficulties that originate in the 
richness of the specification language. We do not present a formal treatment of 
this question in this paper, but illustrate it with the case study. Consequently, 
this work should be considered as the result of an experience on verification of 
Object-Z specifications by means of transition systems, with STeP as the ver- 
ification tool. The general organization of this paper is as follows. Section 2 
introduces Object-Z and transition systems. Section 3 presents the main idea of 
the verification technique, i.e., transforming an Object-Z class into a transition 
system. Section 4 presents the antenna parameter setting problem, its speci- 
fication and its verification with the STeP environment. Eventually section 5 
concludes with an outline of future research. 



2 Basic Concepts 

2.1 Object-Z 



Object-Z [1] is a formal specification language which extends Z [7] by introduc- 
ing object-orientation. Both are based upon set theory and first order predicate 
logic. Specification written in those languages include two parts: the system 
state and operations on states. Operations are constrained by pre and post con- 
ditions. Specification of an operation is enclosed in a definition scope called 
schema. Object-Z allows to group portions of the state and related operations in 
a class schema. It allows modularity, composition and inheritance. We propose 
an example of an Object-Z class based upon the “heap of matches” game. Two 
players, identified as player 0 and player 1, alternate in taking matches from a 
heap. The player whose turn has arrived decides whether he takes one, two or 
three matches. The player who takes the last match is the game’s looser. The 
Object-Z description of the game class is the following: 



Game 

heap : N 
turn : [0..1] 



^INIT 

heap = 46 
turn — ^ 
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Move 

A{heap, turn) 
take! : [1..3] 

heap take? 
heap = heap — take? 
turn = 1 — turn 



0{{turn = 0) — 0{turn = 1)) 
0{{turn = 1) — 0{turn = 0)) 



Variables heap and turn specify respectively the number of matches in the 
heap and the current player identity. States are seen as bindings of model vari- 
ables to values: the state of an object of the Game class is determined by the 
value bound to variables heap and turn. All Object — Z classes include a schema 
named INIT to specify the set of initial states of the class. The Move schema 
specifies the class operation, a game move, and illustrates some notational con- 
ventions of Object — Z. The A statement indicates the portion of the state that 
is modified by the operation. Schemas that define operations are splitted in 
two zones by a short horizontal line. The upper zone specifies the portion of 
state involved in the operation and the operation parameters. The lower zone 
is occupied by predicates that express operation conditions. Another notational 
convention refers to the so-called before/after predicates. Primed variable names 
denote the value to which the variable is bound after the operation, unprimed 
variable names denote the value to which the variable was bound before the 
operation. Consequently, predicates without primed variables can be seen as 
operation preconditions and predicates with mixed primed and unprimed vari- 
ables describe the effect of the operation on the state (i.e., the variable binding). 
Finally, a variable name followed by the question mark (?) distinguishes an oper- 
ation’s input parameter and a variable name followed by the exclamation mark 
(!) distinguishes an operation’s output parameter. As for operation schemata, 
the class schema can be separated in two zones by a short horizontal line. The 
lower zone, if present, includes one or more temporal logic formulas, the history 
invariants. As we will examine in the sequel, history invariants allow to express 
liveness and safety constraints on the computations an object of the class can 
undergo, see [6] for a discussion on Object — Z classes and history invariants. 
In our example, the given invariants state that game players should alternate 
in executing game moves. From the given specification of Move operation, this 
constraint is satisfied by all the possible computations of any instance of the 
game and the history invariants could be omitted. 

2.2 Transition Systems 

We intend to use transition systems to provide a semantics to classes of Object — 
Z. The intended meaning or “type” of an Object-Z class is the set of compu- 
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tations that objects of the class can undergo. A transition system is a compact 
representation of a set of computations and therefore appears as an adequate 
representation for the semantics of an Object-Z class. Furthermore, a number 
of verification techniques have been defined to check transition system models 
against temporal logic formulas. 

A transition system S =< — , S, — e, — c, O > includes a set — of typed variables, 
a set S of states, a set — e of elementary transitions, a set — c of compound tran- 
sitions and an initial conditions 0. Variables — = — o p group in three 

classes: input (— i), output (— o) and private (— p). We assume that all common 
types and most of the classical type constructors are available, as it is the case 
for STeP. A state s — A is a valuation of the private variables. As for Z speci- 
fications, the state is determined by the value to which each variable is bound. 
If v p is a variable, we will note s[u] the value bound to v in state s. Natu- 

rally, state s considered as a valuation function can be inductively extended to 
expressions of any kind. Particularly the initial condition 6* is a predicate such 
that. So is an initial state if and only if sq[ 0] = true. We say that sq satisfies 0, 
which is noted sq 1= 0. 

The sets — e and — c contain respectively the elementary and the compound tran- 
sitions. Both represent state changes, i.e., functions of the kind: A — PA. 
Generally, an elementary transition r e is described by its transition rela- 

tion pr, i.e., a conjunction of predicates. As for the Z notation, we adopt the 
before/after convention to write those predicates. Among many possible general 
forms for a transition relation, we adopt the following: 

= Pre{T) - (v^ = Expi) (?;„ = Expn) 

where Pre{T), a predicate with only unprimed variables, is the transition’s pre- 
condition: s is a source state for r if and only if s 1= Pre(T). For each conjoint 

(vj = Expi), Vi p o and Expi is an expression without primed variables. 

The set ^i, p o is the subset of variables which change value as a 

consequence of the transition triggering. Finally, in the case of elementary tran- 
sitions, unless otherwise stated, we assume that for each v v\, v„— there 

is an unwritten conjoint (v = v), meaning that variables that do not appear in 
p(t) are supposed to be left unchanged by the transition. 

Compound transitions are subsets of elementary transitions noted [ti; ; t„]. 

Compound transitions should be considered as atomic: components of compound 
transitions do not interleave with other transitions of S. We introduce compound 
transitions to account for the atomicity of Object-Z class operations, as will be 
seen in section 3.1. We note — (pr) the set of primed variables of transition 
relation p^.. A compound transition [ri; r„] is coherent if and only if: 

-u, T, - [ti, , T„] -i (Pn) - - (Pr,) = 0 

A computation of transition system S =< — , A, — e, — c, 0 > is a sequence 

(J . Sq ; *^1 J 5 A ’ 

of states such that so 1= 0 and for every Si,i — 0, at least one of the following 
possibilities is verified: 
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—There is a t e such that Si \= Pre{T) and — r(si). 

— There is a coherent compound transition [ti; r„] c that verifies what 

follows. Let £ = — rf , , r^—he the set of components of Tc enabled in Si (i.e., 

for all j, Si 1= Pre{Tj)), then £ = 0 and Sj+i - rf (sj) 

We note C(S) the set of all computations of transition system S. 

3 Verification Technique 

3.1 Prom Object-Z Classes to Transition Systems 

A class specification written in Object-Z can bee seen as the description of 
an abstract machine. Objects of the class are instances capable of producing 
computations of the machine, as sequences of state changes caused by operations. 
The aim of the proposed transformation is to obtain, from the definition of the 
class, written in Object-Z, a compact representation of the set of computations 
an object of the class can produce. This representation is intended to take the 
form of a transition system. The intended result of the transformation is a triple 
(5',Al, — ) where S =< —,U,—e,—c,0 > is a transition system as defined in 
section 2.2, A and — are sets of linear temporal logic (LTL) formulas called 
respectively axioms and history invariants. A simple Object-Z class definition 
has the following elements: 

ClassName 

type definitions 
constant definitions 
state schema 
initial state schema 
operations 

history invariants 



An Object-Z class named cl is characterized by the following sets. Attr{cl) is 
a set of class attributes, declared in the state schema, Param{cl) is a set of 
operation parameters. Both are subsets of a set of identifiers such that Attr{cl) — 
Param{cl) = 0. 

State{cl) — Attr{cl) — Val is the set of class states, a subset of the finite 
partial functions from attributes to values. The set Val contains all possible 
values of attributes of any type. Finally, Op{cl) is the set of class operations. We 
introduce the auxiliary functions tt^ : Op{cl) — PParam(c^) and tTq : Op{cl) — 
P Param{cl) that give respectively the set of input and output parameters of an 
operation. 

We explain now the translation of a simple Object-Z class named cl towards 
a model with =< > and illustrate it 

with the heap of matches game. We state that: 

= Attr{cl), = y 7T,(o), = y 7To(o) 

o Op{cl) o Op{cl) 
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SO that, for the Game class we have — = -heap, turn— = -takel— 

and = 0. 

State schema of the form [declaration part —Axp, ; Axn] declares attributes 

and, optionally, states a list of axioms relative to declared attributes. Axioms 
Ax \ , , Axn are first order predicates on the attributes defined in the declara- 

tion part. We state that: 



= —Axi, AXn — 

The general form of the initial state schema is INIT = [Pri] ; Pr™] where 

the Pri{i — [l..m]) are first order predicates on the class attributes. We state 
that: 

0-1 = Pn Pr„ 

so that, for the Game class we have = (^heap = 46) — {turn = 0). 

The class operations OperationName = [declaration part -predicate list] are the 
portion of the specification which is translated towards the transitions of 
In many cases, an operation gives rise to a set of elementary transitions. Let 

— ° = -^i, ,Ti — he the set of elementary transitions resulting from operation 

o — Op{cl). We distinguish the following cases: 

—if — ° is a singleton (i.e., = ^— ), then r 

— if — ° , T„— , with n > 1 then let Tc = [u; r„] provided 

that Tc is coherent. 

Given the richness of the Object-Z language, a detailed definition of all the 
translation rules from operations into transitions is a difficult task. We will 
illustrate some aspects of the translation principles through the Game example 
and also through the case study. Operation Move of the Game class gives rise to 
transition as follows. The predicate with unprimed attributes determines 

the precondition: Pre{r^°'^^) = {heap — takel). The predicates with mixed 
unprimed and primed attributes determine the rest of the transition relation. In 
the case of the Game example, the transition relation is straightforward: 

p^-Move = {heap — takel) — {heap = heap — takel) — {turn = 1 — turn) 

and we have: -Game ^ _Move ^ _^Move_^ 

Finally, the history invariants part of the class specification contains a list of 
LTL formulas Hi , , Hp . We state: 

cl TJ TJ 

— — —ill, 5 lip — 

So that we have —Gome _ = 0) — Q>{turn = l)),D{{turn = 1) — 

Q>{turn = 0))— Operations that translate to compound transitions are typically 
those which are specified by quantified formulas. In the case study we present 
rules to obtain compound transitions from operation specifications in which vari- 
ables bound by quantifiers have finite types, such as intervals of natural integers. 
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3.2 Validity, Satisfiability, and Consistency 

We present now the meaning of sets A and — that have been introduced in section 
3.1. We use the fact that computations of transition systems can be models of 
LTL formulas. Mathematical logic gives a precise meaning to the word model, 
by defining the satisfaction relation between “universe of discourse” entities 
(models) and logic formulas. Let us begin by a quick remind of LTL formulas 
and their satisfaction relation. 

LTL extends predicate calculus with new logical operators such as O) □> O, 

called the temporal operators. If Fi and F 2 are well-formed formulas so are 
O^’i, F 1 —F 2 , DTi and <}Fi. State formulas are formulas without temporal 
operators. State-quantified formulas are formulas such that temporal operators 
do not appear in the scope of quantifiers. 

The natural model for LTL formulas on a set V = , u„ — of variables are 

the so called Chains, i.e., sequences of valuations of V noted: 

with, for all j, Sj : V — Dom{V), where Dom{V) denotes the domain where 
all variables of V take their values. We note s[u] the value of variable v — V 
in state s. The satisfaction relation (N) is defined as follows. If f is a state 
formula, then (cr,j) 1= F, i.e cr satisfies F at position j, if and only if sj 1= F 
(i.e., Sj [T'] = true). If Fi and F 2 are temporal formulas, the relation 1= is defined 
inductively: (cr, j) 1= Q^i if ^md only if {a,j -b 1) 1= Fi; (a,j) 1= F 1 —F 2 if and 
only if there exists k — j such that (cr, fc) 1= F 2 and for all i such that j < i < k, 
(cr, i) \= Fi; (cr, j) 1= <f>Fi if and only if (cr, j) 1= true— Ti; (cr,j) 1= DTi if and only 
if {(T,j) 1= — O— Fi. The set of chains that satisfy an LTL formula F is noted 
Sat{F). 

Given an Object- Z class cl and its associated semantic entity fh® 

set A’^'' = —Ai, , Am— of axioms defines the state space of cl as the set: 

-r"' ^ N Am- 

in other words, the axioms restrict the set of states of the transition system 
in order to ensure that A‘^’‘ is valid. 

To define the meaning of the history invariant set, let us remind section 2.2, 
where we defined the set C{S) of computations of a transition system. We state 
that S‘^’’ is consistent, with the set = —Hi , — of history invariants if 

Sat{Hi = 0. In other words, — is expected to be satisfiable 

relatively to 

4 Case Study 

4.1 The Radio-Mobile Network Example 

In order to illustrate the specification and verification approach, we choose an 
example from the Radio-Mobile Network (RMN) design problem. Radio-mobile 
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Fig. 1. Antenna parameter setting problem 



communication relies on a network of antennae to cover a given area of territory, 
in order to ensure communication services such as mobile phones. The design of 
a RMN includes three main stages: antennae positioning, parameter setting and 
frequency allocation. 

We are concerned here with the parameter setting stage: once the antennae loca- 
tions have been determined in the positioning stage, the parameter setting prob- 
lem deals with the issue of Quality of Service (QoS) optimization. The antenna 
parameter problem has yet been presented. Indeed, [3] gives an implemented 
solution to the problem, and in [2] we specify the problem and we simulate the 
specification. 

For each antenna, three parameters need generally to be adjusted: emission 
power, tilt and azimuth. On the other hand, QoS includes several aspects, such as 
coverage, traffic, interference and handover. To optimize QoS, a trade-off must 
be found. For instance, coverage and handover ask for higher emission power 
while interference avoidance asks for lesser radio energy. 

In order to solve the parameter setting problem, the area to cover is partitioned 
into a set of meshes whose size vary from 25 to 100 square meters, depending on 
the type of land, as illustrated by figure 1, which resumes the parameters setting 
problem. 

For the sake of clarity, we restrict our example to the of emission power set- 
ting problem, of which we present now a formal description. Given a set A = 
-oi, , a„— of antennae and a set M = -mi, ,mk—oi meshes, the follow- 

ing functions define the radio-propagation upon the considered area. Function 
Fade : M — A — E allows to calculate the mesh-local variation of the field 
emitted by each antenna. Function Power : A — E gives the radio-electric 
emission power of each antenna. Function F : M — A — E allows to calcu- 
late the field intensity in any mesh, due to each antenna emission. As a matter 
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of fact, for mesh rrii and antenna aj, the field intensity can be calculated as 
F{rrii, ttj) = f{Fade{mi, aj), Power(aj)), for a given function /. In this example 
we assume that / is simply the product between emission power and attenuation: 



F{rrii, ttj) = Fade{rrii, aj) —Power(aj) 



4.2 Specification 

The specification of the antennae parameter setting problem is structured in 
three classes. The first specifies the terrain upon which antennae are situated, 
the second specifies an antennae and the latter specifies the system as a whole. 
We suppose that antennae and meshes numbers are fixed and known. They are 
specified by the following schema. 

Types MESHID and ANTENNAID allow to identify each mesh and each an- 
tenna. Constant function Fade gives, for each antenna, the field attenuation in 
any mesh and thereby allows to calculate field intensity in any mesh, due to 
any antenna. We adopt the view of identifying discrete emission power levels, as 
defined by type POWERLEVEL. The only state variable is Field which, for any 
mesh, gives a field intensity vector indexed by the set of antennae identifiers, 
the contribution of each antenna to the mesh’s field. Operation ChangeField 
allow to calculate the contribution of an antenna to the field after a change in 
antenna’s emission power. Operation MeasureField returns, for a given antenna, 
the field it contributes to any mesh. Operation Detectinterference returns, for 
a given antenna, the indication of whether it interferes another antenna in any 
mesh. 

Terrain 

n : N [ ] 

k-.n [ ] 

n < k 

MESHID == [l..k] 

ANTENNAID == [l..n] 

POWERLEVEL == [0..100] 

Fade : MESHID - ANTENNAID - K 

-i : MESHID, j : ANTENNAID -0 < Fade{i,j) < 1 



Field : MESHID - {ANTENNAID - K) 



INIT 

-m : MESHID- a : ANTENNAID -Field{m){a) = 0 
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ChangeField 

AField 

EmitedPowerl : POWERLEVEL 
Antidl : ANTENNAID 



-m : MESHID - 

Field {m) = Field{m) Antidl — Fade{m, Antidl) —EmitedPowerl— 



MeasureField 

Antidl : ANTENNAID 
FieldMeasurel : MESHID — K 

— m : MESHID —FieldMeasure\{m) = Field {m){ Antidl) 



Detectinterference 

Antidl : ANTENNAID 
Interfered'. : MESHID - 1 

— m : MESHID — Interfered', {m) = 

—a : ANTENNAID —a = Antidl — Field{m, a) — gateq — 
Field{m, Antidl) — gates 



An antenna is specified by its identity, emission power and coverage at- 
tributes and operations. Operation SetCoverage determines, from field intensity, 
the meshes covered by the antenna. Operation SetPower bases on interference 
to determine whether the antenna increases or decreases its emission power. 
Operation Emit outputs the antenna’s emission power. 



Antenna 

n : N 
k : N 



I n < k 

MESHID == [l..k] 

ANTENNAID == [l..n] 
POWERLEVEL == [0..100] 

Antid : ANTENNAID 
EmissionPower : POWERLEVEL 
Covered : MESHID - 1 
Coverage : N 
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INIT 

EmissionPower = 0 
Coverage = 0 



SetCoverage 

A{Covered, Coverage) 

Identity'. : ANTENNAID 
FieldMeasurel : MESHID - K 

Identity'. = Antid 

—m : MESHID — Covered (m) = {FieldMeasurel {m) > gateg) 
Coverage = {Covered > true) 



SetPower 

A ( EmissionPower) 

Identity'. : ANTENNAID 
Interfered! : MESHID - 1 

Identity'. = Antid 
{Interfered! > true) < Imax — 

EmissionPower = EmissionPower + A\Power 
ff {Interfered! > true) — Imax — 

EmissionPower = EmissionPower — A 2 Power 



Emit 

Identity'. : ANTENNAID 
Power'. : POWERLEVEL 



Identity'. = Antid 
Power'. = EmissionPower 



The system composed of antennae and meshes is specified by Communi- 
cationSystem class. It includes an instance of the Terrain class and a set of 
instances of the Antenna class, indexed by the set of antenna identifiers. 

CommunicationSystem 

terrain : Terrain 

antenna : ANTENNAID — Antenna 

—a : ANTENNAID —antenna{a). Antid = a 



INIT 

terrain. INIT 

—a : ANTENNAID —antenna{a).INIT 
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SetAllPowers 

A{antenna) 

—a: ANTENNAID —antenna{a).SetPower — terrain. Detectinterference 



SetAllCoverages 

A{antenna) 

—a : ANTENNAID — terrain. MeasureEield — antenna{a).SetC overage 



SetField 

A{terrain) 

—a : ANTENNAID — antenna{a) . Emit — terrain. ChangeEield 



□ ((op = SetAllPowers) — Q{op = SetField)) 

□ ((op = SetField) — O{op = SetAllCoverages)) 

□ ((op = Set All Coverage) — O{op = SetAllPowers)) 



4.3 Verifying the Object-Z Specification 

Obtaining the Transitions System We discuss now some components of 
the transition system that results from the Object-Z specification of the case 
study. We do not express formally in this work the rules that guide such a trans- 
formation. Rather, we give an informal presentation to justify the transitions 
resulting from some constructs frequently used in the case study. An important 
issue concerns the evaluation of compound transitions by evaluating sequentially 
their elementary component transitions. This can be made under some condi- 
tions that we present below. 

Many assertions that specify the operations of our model are universally quanti- 
fied formulas, with bound variables ranging in sets MESHID and ANTENNAID . 
The general idea to translate such assertions into transitions is as follows. With 
formula: 

—i : [l..fc] —Prei — {var^ = Expi) 

where Prei is a precondition, vari is a variable name and Expi is an expression, 

we associate the compound transition [ti; Tk] such that for all i — [l..fc], 

the transition relation is: 



pin) = Prei - {var^ = Expi) 

If for all i,j — [l..fc] we have i = j — vari = varj then we have a coherent 
transition. Moreover, this compound transition can be evaluated sequentially if 
neither Prei nor Expi contain any variable other than vari. 

Another Z construct frequently used in our specification is the range restriction 
operator (>). We used it when, given a predicate on Mesh, we had to count 
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the domain elements that mapped to true. A general rule to translate such a 
construct towards a set of transitions, is the following. Given a predicate Pred : 
[l..fc] — B, with formula: 



count = ^{Pred{i) > true) 

we associate the compound transition [{count =0); ri; Tk] such that for 

all i — [l..fc], the transition relation is: 

p{Ti) = Pred{i) — {count = count + 1) 

Indeed, this is not a coherent compound transition but we can obtain the ex- 
pected result by evaluating sequentially each one of the component elementary 
transitions. 

We dealt with some other aspects of the Object-Z specification, such as aggre- 
gation, before translation towards transition systems. As a matter of fact, we in- 
spired from the approach to class aggregation presented in [6] . As an example, the 
CommunicationSystem class results from the aggregation of classes Terrain and 
Antenna. Operations of the aggregate class were defined by applying operator 
— to operations of component classes. To obtain the translation of those opera- 
tions towards transitions of the transition system, we first applied schema trans- 
formations due to the — operator of [6]. As an example, consider the SetField 
operation, which refers to operation antenna {a). Emit — terrain. ChangeField. 
We have: 

antenna{a) .Emit — terrain. ChangeEield 

A{terrain) 

ChangeEield. Antid? = Emit .Identity \ 

Terrain. EmitedPowerl = Emit.Powerl 
terrain Terrain :: ChangeEield terrain 



where, according to operation antenna{a) . Emit , we have: 

Identityl = antenna{a).AntId 



and 



Powerl = antenna{a) .EmissionPower 



On the other hand, remind that relation terrain Terrain :: ChangeField terrain 
states that terrain and terrain are related by the aggregated operation exactly 
as they are related by operation ChangeField of class Terrain. If we apply the 
equalities and the definition of the terrain Terrain :: ChangeField terrain rela- 
tion, we obtain: 




Verification of Object-Z Specifications by Using Transition Systems 235 



antenna{a) .Emit — terrain. ChangeField 

A{terrain) 

—m : MESHID —Field (m) = Field{m) antenna{a).AntId — 

Fade{m, antenna(a) .Antid) —antenna{a).EmissionPower— 



which is the predicate to be translated towards transitions. 

Verifying with STeP: Some Implementation Details The use of STeP 
as a verification tool requires the expression of the resulting transition system 
according to the STeP transitions syntax. As the later do not include the notion 
of compound transitions defined in section 2.2, we defined an implementations 
of compound transitions based on the sequential evaluation of elementary tran- 
sitions components. To ensure atomicity of compound transitions we used lock 
variables. We factorized sets of transitions by implementing loop constructs. Fi- 
nally, Functions on domain MESHID (respectively ANTENNAID) were imple- 
mented as arrays indexed by [l..fc] (respectively [l..ri]) and functions on domain 
MESHID — ANTENNAID were implemented as arrays indexed by [l..fc] — [l..n]. 
As an example consider operation SetCoverage of class Antenna, which produced 
the following transition relations: 

Pi = {lock = FREE) — {index = 1) — {Coverage = 0) — {lock = TAKEN) 

P 2 = {index — 1) — {index < k) — {FieldMeasurel[index] — gateg) — 
{Covered [index] = true) — {Coverage = Coverage -I- 1) — {index = index + 1) 
P 3 = {index — 1) — {index <k)— {FieldMeasurel [index] < gateq) — 
{Covered [index] = false) — {index = index + 1) 

Pa = {index > k) — {index = 0) — {lock = FREE) 

We used the STeP model-checker to verify the satisfiability of the history 
invariants of class CommunicationSystem, on a simple communication system 
composed of two antennae and ten meshes. The STeP model-checker proves 
or refutes validity of LTL formulas relatively to a transition system, to estab- 
lish the satisfiability of history invariant H one must actually establish that 

— H is not valid. Concerning our case study, we checked separately each one 
of the three temporal formulas of class CommunicationSystem. For instance, 
the satisfiability of the first formula was checked by establishing that formula 

— {{op = SetAllPowers) — Q{op = SetField)) was not valid. 

We first verified some properties of separated classes. For the Antenna class, we 
verified the satisfiability of formula Fi = C>{Coverage — CoVmin) with CoVmin 
being a minimal number of covered meshes. This property represents the pos- 
sibility of an important result to be obtained, i.e., an antenna covering at least 
a minimal number of meshes. As already mentioned, the STeP model-checker 
proves or refutes validity of LTL formulas relatively to a transition system. Con- 
sequently, STeP was asked to verify formula \3{Coverage < CoVmin)- A coun- 
terexample was rapidly established by STeP. The number of states visited by the 
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model-checker was 48. Next we verified a safety property, expressed by formula 
F 2 = \3{{Coverage < k) — {EmmissionPower < 100)), to mean that even when 
all meshes are covered by an antenna, the maximal power level is not exceded. 
This property was refuted by STeP with a counterexample, thereby motivating 
a change in the Antenna specification. The modified version satisfied F 2 , but 
verifying this formula took considerable amounts of time, visiting more than 
200000 states. 



5 Conclusion 

Formalisms like Z and Object-Z include in a unique specification language two 
important conceptual domains. On one side, by adopting the first order pred- 
icate notation, they belong to the specify with logic realm. On the other side, 
as they describe system state and operations on states, Object-Z also relates to 
more operational styles of specification. In this work on verification of Object- 
Z specifications we propose some rules to transform an Object-Z class into a 
transition system, in order to use verification tools such as the STeP environ- 
ment. Rather than general rules, we present the approach by applying it to a 
case-study. The proposed informal rules transform operations of the class in sets 
of simple transitions grouped in indivisible compound transitions to represent 
operations of the class. Future research should concentrate on a better under- 
standing of problems related to the transformations from Object-Z operations 
towards compound transitions, that preserve! the properties of operations ex- 
pressed with first order predicates. Formal presentation of a set of well defined 
transformation rules is also necessary to consolidate the approach. 
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Abstract. We present work on a formal model for the composition of object- 
oriented modules, or hyperslices, which represent different perspectives on the 
system being built. With the model, we should be able to study existing ap- 
proaches such as subject-oriented programming, as well as extend other object- 
oriented languages, such as the UML, to accommodate the use of hyperslices. 
We show here a sample of the specification language that accompanies the for- 
mal model, and a small example of its use. 



1 Introduction 

The idea of dividing a system description into various perspectives, each of which por- 
trays some aspect of the system, has been the topic of recent intensive research. Tech- 
niques such as subject-oriented programming [9] and aspect-oriented programming [14] 
explore the possibilities of having multiple representations of the same entity from the 
problem domain. The need arises for a formal model that brings together what is com- 
mon about the various multiple-perspective methods, particularly within the object- 
oriented paradigm. Such a model would allow for strengthening of existing techniques 
with the possibility for formal proofs and consistency checks, and serve as the basis 
for extending popular design and implementation languages with multiple-perspective 
capabilities. This work attempts to fill this gap. 

In section 2 we discuss the need for multiple-perspective decomposition and present 
its different categories. We then discuss issues related to multiple-perspective decom- 
position restricted to the object-oriented paradigm in section 3. Section 4 shows the 
proposed model, followed by a small example of its use in section 5. 



2 Multiple-Perspective Decomposition 

One of the most widely accepted tenets of software development is the fact that com- 
plex problems must be divided into smaller parts that are easier to understand and work 
with. Traditional approaches to modeling such as structured analysis and object orien- 
tation take a top-down approach, where a system is decomposed into several parts, each 
of which is again decomposed until each part is simple and cohesive. The parts are then 
implemented independently and composed to form the desired software system. The 
exact nature of the entities that form each part varies between approaches, but typically 
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each unit of the decomposition is encapsulated in a procedure (functional decomposi- 
tion), module, or class (object decomposition). It is common to think of each of these 
units as pieces in a larger puzzle, all of which ht together to form the solution. 

Recently, new approaches to problem decomposition have been the subject of re- 
search. It is often useful to view the entire problem from a single perspective, discarding 
all the problem elements that are not relevant to the perspective, and thereby reducing 
problem complexity. The problem then becomes easier to understand and manage than 
when viewed in its entirety. In contrast to the top-down approach for functional decom- 
position mentioned in the previous paragraph, each perspective can be thought of as a 
glass sheet with some aspect of a painting: one sheet may have a black outline of the 
painting; another, its colors; others may have shadings, textures, and so on. Superim- 
posing all glass sheets forms the complete painting. 

What distinguishes this “multiple-perspective” decomposition from other forms of 
divide-and-conquer is the fact that the decomposed parts are not disjoint. In other ap- 
proaches to decomposition, any entity from the problem domain appears in only one of 
the pieces after decomposition - no entity appears in more than one piece. By contrast, 
an entity may appear in any number of perspectives, and its definition can be different 
in each perspective. 

We frame our concept of perspective in software engineering rather broadly using 
the following two definitions. 

- A description of a software system has multiple perspectives if it is explicitly di- 
vided into two or more partial descriptions, and there are entities from the problem 
domain that appear in more than one partial description. 

- A method uses multiple perspectives if it enforces the description of software with 
multiple perspectives and provides rules governing how perspectives are related to 
one another. 

These definitions allow a wide variety of methods to be thought of as using multi- 
ple perspectives. We divide them into three categories according to the kind of partial 
description used: architectural, domain-specihc, and user-defined perspectives. Our re- 
search focuses on methods that allow user-dehned perspectives. In order to clarify the 
relationships among the proposed models, we discuss the three categories of multiple- 
perspective methods. 

2.1 Architectural Perspectives 

Structured analysis methods such as the one proposed by Gane and Sarson [8] use 
two different diagrams to describe a system: a module hierarchy chart describing the 
division of the system into modules, and a data flow diagram describing how data was 
transferred between the modules. Each diagram represents a partial description of the 
system, and contains representations of the same entities from the problem domain, and 
therefore ht our dehnition of a perspective. Modern object-oriented analysis and design 
methods such as the Object Modeling Technique (OMT) [18], Goad and Yourdon [5], 
UML [3], and others, all use different perspectives to describe a software system. 

However, in all of the above, the perspectives are dehned by the method and re- 
flect different modeling or descriptive capabilities. For instance, a model may dehne 
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structural relationships between entities, such as containment or association, while an- 
other may define behavioral aspects of each entity. Each perspective is usually described 
using a different language. This kind of description is often called an architectural per- 
spective since each represents a certain aspect of the system’s architecture. An impor- 
tant characteristic of architectural perspective decomposition is that it is independent of 
the problem domain. Dividing a problem into structural and behavioral views tells you 
nothing about the problem itself [13]. 

2.2 Domain-Specific Perspectives 

There are other methods that allow the use of predefined perspectives, but instead of 
reflecting architectural aspects, the perspectives represent aspects of a specific problem 
domain. An example of this kind of method is the ISO standard for Open Distributed 
Processing (ODP) [11], which is geared towards the description of distributed systems. 
In ODP, systems may be described from any of five viewpoints. The five were chosen 
because they represent different and important perspectives relevant to the domain of 
distributed systems. These are domain-specific perspectives. 



2.3 User-Defined Perspectives (Hyperslices) 

Other methods allow for the decomposition of a problem into user-defined perspectives. 
These depend on the domain of concern, and therefore may be different from problem 
to problem. Also, the number of perspectives is not limited or predefined by the method. 
Methods supporting this type of decomposition were first developed for use in require- 
ments elicitation, where it is common to have different stakeholders who have different 
ideas about the problem at hand, all of which must be captured. All perspectives are 
usually, but not always, described using the same language. 

Various approaches have been proposed that allow user-defined perspectives. The 
approaches work at various levels of abstraction, and give different names to the units 
of decomposition. Table 1 lists some of these approaches. 



Approach 


Unit name 


Level of abstraction 


Viewpoints [7] 


viewpoint 


requirements analysis 


Role models [15] 


role 


design 


Contracts [10] 


contract 


design 


Aspect-oriented programming [14] 


aspect 


implementation 


Subject-oriented programming [9] 


subject 


implementation 



Table 1. Approaches to decomposition with multiple user-defined perspectives 



As can be seen from the table, the field is quite overloaded with different termi- 
nology for similar concepts. In recent work, Tarr et al. have coined the terms Multi- 
Dimensional Separation of Concerns (MDSC) to designate the discipline of multiple- 
perspective decomposition, and hyperslice to designate a unit of decomposition that 
follows this discipline, at any level of abstraction [20]. 
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The most appropriate definition of hyperslice for our purposes is Daniel Jackson’s 
concept of view: 

“A view is a partial specification of the whole program, in contrast to a module, 

which is a specification - often complete - of only part of the program” [12]. 

A hyperslice, like a “view”, specifies some aspect of the entire program. 

The form of decomposition afforded by hyperslices is useful in many levels of soft- 
ware design. During requirements elicitation, for instance, the engineer often has to 
deal with many different people who are stakeholders in the system to be developed. 
Each of these stakeholders may have different perceptions about the problem at hand 
and of the desired behavior of the system. Hyperslices are a natural way of represent- 
ing each stakeholder’s perspective on the system so that later a coherent picture can 
be formed. The same advantages found at the requirements analysis phase carry over 
into later phases. Having design and implementation modules that correspond to user 
requirements provides easy requirements tracing. In the next section we discuss the use 
of hyperslices with object-oriented systems. 

While the ideas behind MDSC are useful, there are issues that must be tackled when 
applying it, One of the most pressing of which is is consistency. When we allow more 
than one representation of an entity, we must somehow ensure that the representations 
do not contradict each other. Being able to detect inconsistencies and deal with them is 
one of the challenges of MDSC, and formal models that allow reasoning are an indis- 
pensable aid towards achieving this goal. Easterbrook et al. have studied mechanisms 
for dealing with inconsistencies when using requirements-level hyperslices [6]. 

There are also conflicts that do not manifest themselves as logical inconsistencies, 
but as a form of interference between hyperslices; the goals of the viewpoints may be 
mutually interdependent and actions taken by one may cause undesired behavior in the 
other. This is analogous to the problem of feature interaction in telephone systems [4]. 
A formal model should aid in the detection of such interactions. 

There is yet no formal model to allow a comparative study of the properties of the 
various existing approaches to hyperslices; our work intends to fill that gap. However, 
mention should be made of Ku [19], a formal object-oriented language for hyperslices 
currently under development at Imperial College. Once our model and Ku are both 
complete, it will be interesting to compare analytical results derived from the two inde- 
pendent studies. 



3 Object-Oriented Hyperslices 

While the concepts behind MDSC (Multi-Dimensional Separation of Concerns) are 
widely applicable, much of the work in the field involves its use together with the 
object-oriented paradigm. Many of the shortcomings of object-orientation are addressed 
by MDSC. Among these are rigid classification hierarchies, scattering of requirements 
across classes, and tangling of aspects related to various requirements in a single class 
or module. Eor a detailed treatment and motivation for the use of multiple perspectives 
in object-orientation, we refer the reader to Tarr et al. [20]. 
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We are interested in the subset of MDSC that deals with object-oriented systems. 
We consider a hyperslice to be a module that conforms to some accepted model of 
object-orientation, made up of classes and class relationships such as containment and 
inheritance. For an object-oriented system to fit into the category of MDSC, however, 
there must be entities from the problem domain that appear in more than one module. 
That is, there must be classes in different modules that represent separate aspects of the 
same entity. Since a hyperslice is meant to be a complete encapsulation of some relevant 
aspect of the system, the classes in a hyperslice should not have any links to classes of 
other hyperslices. Each hyperslice should be a well formed unit that can be understood 
in isolation. 

As an example, one of the hyperslices in a system may be concerned with display- 
ing information about the various objects that concern the system. The classes in this 
hyperslice should have methods to output information, and whatever attributes that are 
relevant to these methods. Other attributes or methods, such as those concerned with 
synchronization, or with some form of computation over the data, should not appear in 
this hyperslice. However, the hyperslice should contain all classes that have an output 
aspect to them. 

Splitting an object-oriented description into various hyperslices gives a level of 
separation of concerns that offers significant advantages over traditional approaches. 
Among these advantages are the following: 

Requirements-based modularization since entities are allowed to appear in more 
than one unit of decomposition, and to be only partially specified in any one unit, 
it is possible to have units that encapsulate a single requirement from the problem 
domain. For instance, if some of the data is to be stored and retrieved from a net- 
work server, a hyperslice would be defined containing all classes that have data 
belonging in the server. Each class would have only enough detail defined to allow 
the relevant storage operations to be performed. The same classes might appear in 
other hyperslices, but no mention of server storage would be found in them. 
Decentralized development since classes can be represented differently in different 
hyperslices, classes need no longer be owned by developers who are responsible 
for all details regarding that class, but each developer can be responsible for a part 
of the shared class. 

Unanticipated composition designs for separate programs can be thought of as hy- 
perslices of an integrated application; a hyperslice-enabled method would allow 
the developer to describe how the programs are to be joined together. 

Software evolution along the same lines, features can be added to existing systems 
as separate hyperslices; this would allow changes to be made without requiring 
modifications to existing designs. An example of hyperslices applied to evolution 
can be found in [2]. 

3.1 Composing Hyperslices 

Since each hyperslice is a plain object-oriented module, it can in theory be described 
using any object-oriented language, at any level of abstraction. Having defined the hy- 
perslices, they must now be composed to form a complete system. This is where the 
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MDSC paradigm differs from other approaches to decomposition. Some approaches, 
such as that advocated hy module interconnection languages, define interfaces for mod- 
ules, with provided and required functionality, and match provided functions with re- 
quired ones across modules. Others, such as frameworks, use inheritance as the basic 
composition mechanism. In MDSC, each hyperslice is well formed and independent, 
and does not require other hyperslices. There are classes, however, that exist in various 
hyperslices. In order to form the desired system, we must establish the correspondence 
between these classes. 

Correspondence is the specification of what elements match between hyperslices, 
and the semantics of each match. There are many ways in which matching can affect 
the overall behavior of the system. Matched classes may have complementing behavior, 
or one’s behavior may override the other, or they may interact in more complex ways. 

The granularity of correspondence is an issue. Using classes as the unit of corre- 
spondence (also called join point [14]) seems to be too coarse. There are many dif- 
ferent ways in which we may wish to specify that entire classes are matched, and the 
model would require a large variety of different correspondence operators. On the other 
hand, using single program statements is too fine-grained. Specifying correspondence 
would require understanding implementation details, and would be very complex. In 
our model, we choose the middle road and use methods as the smallest elements that 
can be matched. Ossher and Tarr argue in favor of this approach [16]. We define corre- 
spondence operators that allow methods to be matched with various different semantics. 
The semantics describe what method bodies are executed in response to a method call. 

Another issue with regard to correspondence is object binding. This is the specifi- 
cation of how objects of classes with corresponding methods are bound to each other at 
runtime. The description of correspondence is class-based, meaning that a method from 
a class is said to correspond to a method in another class. However, the semantics of 
correspondence are observed during method invocation on particular runtime objects. 
If a method invocation results in the execution of a method in an object of a differ- 
ent class, we must be able to determine exactly what the target object is. The binding 
specification describes how to determine correspondence between runtime objects. 



4 The Hyperslice Model 

We are interested in studying object-oriented hyperslices with operation-level corre- 
spondence. A language to allow hyperslice composition is under development. This is 
a class-based language that uses methods as the smallest indivisible unit. It is not meant 
to be an executable object-oriented language, but a means to specify formally compo- 
sitions that can be done in any object-oriented design or implementation language. The 
language has two parts, one for class definition and one for composition. 

The model allows us to study properties of techniques that use operation-level cor- 
respondence such as subject-oriented programming [9], and serves as a semantic basis 
for the extension of other object-oriented languages with the required mechanism for 
multi-dimensional separation of concerns. Since subject-oriented programming already 
represents an embodiment of MDSC at the implementation level, one of our interests is 
in extending design-level languages such as UML. 
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4.1 Class Language 

The class language defines the classes present in the system, as well as the call graph 
between the methods of these classes. The semantics of correspondence are specified in 
terms of transformations in the call graph structure. 

Each class is defined as a set of methods. A method has a name and a list of other 
methods that it calls. The internal state of a method is irrelevant. Each method call in 
this list is decorated with the modal symbols □ (always) and O (possibly). At this stage, 
the language is untyped, and does not support parameters to methods, or return values. 

Data attributes are not modeled. Instead, they may be represented as methods, the 
data being the internal state of the method. In fact, any method that does not call any 
other methods can be thought of as an attribute. This approach is related to the one used 
by Abadi and Cardelli in their object calculus [1]. Figure 1 shows the syntax of the class 
language, while figure 2 shows a sample class definition. 



hyper slice ::= class{class} 
class class name method{, method} “}” 
method ::= name[ { called-method } “)” ] 
called-method ::= Oname\<>name 

name ::= an identifier containing letters, hyphens, or a period. The period separates class 
names from method names. 

Fig. 1. Class definition language syntax 



class Tree {nodes, find( □ nodes, O travel-left, O travel-right ), 
travel-left (Dnodes), travel-right (Dnodes) } 

Fig. 2. Sample class definition 



Note that the names inside the parenthesis are not arguments, but the list of methods 
that the method calls. In the example above, the class named Tree has four methods. The 
methods find, travel-left, and travel- right will always call method nodes. The method 
find may, in addition, call methods travel-left and travel-right. The method call list may 
contain methods from other classes, specified by stating the class and method names 
separated by a period (as in Tree . find). 

4.2 Composition Language 

A composition is specified using calling contexts. At the highest level is the program 
calling context. By default, in any context, calling a method results in that method be- 
ing executed. Method correspondence expressions can be used to change the effects of 
method calls. An expression is formed by two method names connected by a corre- 
spondence operator. Each expression can also introduce new calling contexts that have 
scope limited to the execution of the method that precedes the context. 
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Operator 


Call 1 Execution 


Unidirectional 


a followed-by b 


a 


o; b 


a preceded-by b 


a 


b\ a 


a replaced-by b 


a 


b 


Bidirectional 


a merge b 


a 


a; b 


= a followed-by b Ab followed-by a 


b 


b\ a 


a swap b 


a 


b 


= a replaced-by b Ab replaced-by a 


b 


a 



Table 2. Method correspondence operators 



Table 2 shows the correspondence operators and their meaning in terms of method 
calls and executions. The semicolon is used to denote sequence: a; b means that method 
a will be executed and immediately followed by the execution of method b. 

The bidirectional operators merely combine unidirectional ones and exist to add 
brevity to specifications. Many others are possible besides the two shown previously. 
Figure 3 shows the syntax of the composition language. 



context ::= {expression} “}” 

expression name[context] \ name[context] operator name\context] 

operator ::= followed-by | preceded-by | replaced-by | merge | swap 

Fig. 3. Composition language syntax 



Composition expression examples: 

a{b followed-by c} Calls to a will result in the execution of a. During the execution of 
a, calls to b will result in the execution of b, followed by the execution of c. 
x{p followed-by q} preceded-by y{r swap q} A call to x will result in the execution 
of y followed by the execution of x. In the execution of y, calls to r are replaced 
with the execution of q, and calls to q are replaced with the execution of r. In the 
execution of x, calls to p will result in the execution of p followed by the execution 
of q. 



4.3 Object Binding 

The composition operators are described at the class level. However, their effects are at 
the object level. A correspondence operator defines whaf happens when a call is made 
to a specific object. That call may result in the execution of methods in a different 
object. We need a way to determine the object referred to in the execution. Once that is 
determined, objects are bound to each other throughout their lifetime. 

If there is a correspondence expression that matches a method call in a class a to 
a method execution in a different class b, there must be a binding expression detailing 
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how objects of class a are to be bound to objects of class b. A binding expression has 
the form a operator b, where a is the class that has the method called, b is the class that 
has the method executed in response to the call, and operator is a binding operator. 
There can only be one binding expression involving any given pair of classes. 

Currently, our language supports only three binding operators: binds-to-unique, 
binds-to-any, and binds-to-all. The expression a binds-to-unique b means that an object 
of class a is bound to any object of class b, as long as b has not yet been bound to any 
other object of class a. If such an object does not exist, one must be created. Another 
kind of binding is binds-to-any. The expression a binds-to-any b means that an object 
of class a can be bound to any existing object of class b. Finally, binds-to-all means that 
an object of class a will be bound to all existing objects of class b. 

The effect of binds-to-unique is to create a one-to-one correspondence between ob- 
jects. If a binds-to-unique b, then for each object of class a there will be an object 
of class b. The effect of binds-to-any is to create a many-to-one correspondence. If a 
binds-to-any b, a single object of class b is sufficient; all objects of class a can bind to 
that object. Finally, binds-to-all creates a many-to-many correspondence. In this case, 
when a method is called on an object of class a, the corresponding method of class b 
will be executed for all objects of class b. 



5 Example: Concurrent File System 

In this example we will take two independent modules, a simple file system and a con- 
currency control unit, and consider them as two hyperslices, or separate aspects, of an 
integrated system. The system is to give support for concurrency to the file system. 

Hyperslice 1: file system A simple file system hyperslice contains two classes: File 
and Directory. Both allow read and write operations. 

Hyperslice 2: shared buffer The shared buffer hyperslice contains a single class. Mu- 
tex, which encapsulates a shared buffer for use in a concurrent environment by 
multiple threads. The shared buffer contains three methods: read, write, and cs. 
Many readers can access the buffer at the same time, but writers require exclusive 
access. The cs method implements the critical section, which is where the buffer is 
actually manipulated. 

Our intention is to combine the two hyperslices to produce a file system that sup- 
ports execution in a concurrent environment, i.e., that allows many simultaneous users 
to read from a file or directory, but requires exclusive access to write in either of them. 
Figure 4 shows the class definitions for the two hyperslices. 



class File { read( ), write ( ) } 

class Directory { read( ), write ( ) } 

class Mutex { read( □ cs ) , write ( □ cs ) , cs ( ) } 

Fig. 4. Class definitions 
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The Mutex class provides synchronization for the desired system. Our intent is for 
users to still be able to use the File and Directory classes normally. However, before 
the file system operations can be used, the synchronization process must happen. This 
means that the appropriate Mutex method must be executed before the file system 
method. We use a correspondence expression to make sure that this happens, and that 
the appropriate file system method is executed when the Mutex object enters the critical 
section. The four required correspondence expressions are shown in figure 5. 



File. read replaced-by Mutex. read { cs replaced-by File. read } 
File. write replaced-by Mutex. write { cs replaced-by File. write } 
Directory . read replaced-by Mutex. read 

{ cs replaced-by Directory . read } 

Directory . write replaced-by Mutex. write 

{ cs replaced-by Directory .write } 



Fig. 5. Correspondence expressions 



The four expressions have similar structures. Let’s examine the first line. When the 
user calls the read method of a File object, the read method of a Mutex object will be 
executed instead. The method will go through the read access protocol for the shared 
buffer. When it becomes possible to read the shared buffer, the cs method will be called. 
However, the context specified that File.read be executed instead. The file is then read. 
When File.read returns, the rest of the Mutex.read method is executed, releasing any 
locks that may be necessary. Figure 6 shows the flow of control between the hyperslices. 



System File nyttex 




Fig. 6. Flow of control after correspondence 
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File binds-to-unique Mutex 
Directory binds-to-unique Mutex 

Fig. 7. Object binding expressions 

The effect of the binding expressions, shown in hgure 7 is to ensure that each File 
or Directory object will have its own Mutex object. This will allow each hie to have its 
own concurrency access; while a hie is being read, a different hie can be written. Had 
we used binds-to-any, instead, we would have all hies sharing a single Mutex object, 
which would have the effect of only allowing the hie system to write to a single hie at 
a time. This illustrates how the behavior of the system can be modihed by changing the 
binding expressions. 

6 Work in Progress 

Many issues still need to be tackled before the model can he used as a basis for the 
extension of object-oriented approaches. The language is still untyped, and methods 
support neither arguments nor return values. Dealing with these will require work on 
the semantics of the correspondence operators, since the parameters or return types of a 
called method may differ from those of the executed method. The language also needs 
support for inheritance and more complex types of object binding. 

We use transformations to achieve the desired semantics mandated by the corre- 
spondence operations. Since conventional object-oriented languages offer no primitives 
that are equivalent to these operators, the model becomes more useful if the systems de- 
scribed can be converted into systems in the conventional object-oriented model. This 
can be accomplished by a set of semantics-preserving transformations that would mod- 
ify the existing classes to apply the functionality dictated by the correspondence opera- 
tors. 

The formal model underlying the language is under development using the PVS 
language and theorem prover [17]. 

7 Conclusion 

We are providing the formal infrastructure for reasoning about multiple-perspective 
object-oriented systems. Our model is based on method-level correspondence, and is 
simple yet capable of describing the complex relationships that are necessary for this 
form of separation of concerns. We use call graphs to dehne the structure of individual 
hyperslices. Correspondence operations are used to specify changes in the call graph 
structure, and binding operators specify how runtime objects are matched. The example 
shown in this work is small, but illustrates the potential for using the model languages 
in hyperslice composition. 

Once the model has been further expanded to include more object-oriented mech- 
anisms such as inheritance, we intend to use it for formal reasoning about systems 
defined in many of the existing approaches such as subject-oriented programming. In 
particular, we are interested in consistency checking, a constant problem when using 
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this form of decomposition. We also wish to use our semantic infrastructure as the basis 
for extending other object-oriented languages with multiple-perspective capabilities. 
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Definition 1 (Algebraic High-Level Net System). An algebraic high-level 
(AHL) net system is given by 

N SPEC, A, P,T,pre,post,cond,m 

with 

— SPEC SPEC—; an algebraic specification with SPEC E,E (see 

[EM85]), 

— A — Alg SPEC —a SPEC algebra, 

— P : the set of places, 

— T : the set of transitions, 

— pre,post T — Tqp X —P 

the pre- and postcondition functions of T, defining for each transition with 
adjacent arcs the arc inscriptions and the weight, (see Def. 15 for —-operator) 

— cond T EQNS E 

the function that maps each transition to a finite set of conditions over the 
signature with variables representing the firing conditions, and 



~ m - 


- A 


— P the initial marking (see Def. 15). 
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Definition 2 (AHL Net System Morphisms and Categories). Given two 
AHL net systems Ni SPECi, Ai, Pi,Ti,prei,posti,condi,mi for i , 
then an algebraic high-level (AHL) net system morphisms f Ni — N 2 given by 
f fsjAjpJr with 

— fs SPECi — SPEC 2 is a specification morphism, 

— f A Ai — Vf^ A 2 is a homomorphism in Alg SPECi , 

— fp Pi — P 2 maps places to places in Set, and 

~ fr Ti — T 2 maps transitions to transitions in Set, 

and the following abbreviations 

- finsc fs — fp Topi X — Pi — Tqp2 X — P 2 

— fm fs, f A — fp Ai — Pi — A 2 — P 2 

~ fc ~fin fs 

for the induced mappings of arc inscriptions, markings, respectively condi- 
tions, are called 




loose 



— for any t —Ti we have fmsc pre\ t — pre2 /t t 
finsc posh t - pOSt2 !t t 

— fc —condi — cond,2 —fr 

— Im fnip -m2 fp(p) m k Ni 

— Ai ~ Vfj, A2 m m //I m m 

This class of morphisms gives rise to the category QAHLSys. 
transition preserving 
if they are loose and 

— finsc -prei pre2 -fr 
finsc —pOSti pOSt2 — /t 

j 

~ fc —condi cond2 —fr m 

This class of morphisms gives rise to the category AHLSys. 
place preserving 

if it is a loose morphism and the following place preserving conditions hold: 

— fs SPECi — SPEC2 is persistent, that is for the corresponding free 
functor Ffp. Alg SPECi — Alg SPEC2 we have ~Ffs ~ ID 
(see [EM 85 ]). 

fp P fs - fr -P 

and fp p - fs - fr P~ for all p - Pi 
(see Def. 17 for pre and post sets) 

j 

“ /t; fp, and fs are injective 

— m2 fp fM frii k 

— fc —condi cond2 -fr m 

transition gluing 

if it is a loose morphism and the following holds: 

— fp and fs are isomorphisms 

— fM mi fri2 k 

— fr is surjective s. t. for t2 — T2 

prc2 t2 ^ analogously for post, 

mm m 

— cond2 t2 Ut /-i(i2) /c -condi t for t2 - T'2 

mm m 
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Example 1 (Morphisms in Example). 
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Definition 3 (Strict Morphisms). Given a transition preserving AHL net 
system morphism f Ni — N2 with f fs,fA,fp,fT and Ni SPECi, 
Ai,Pi,Ti,prei,posti,condi,fni fori , . f is called 

1. marking strict 

if fM fni p np 2 fp{p) the initial marking of the source net is placewise 
equal to the target net. 

2. strict 

if it is marking strict, and moreover fp, fp, and fs are injective, and fs is 
strict in SPEC. 

Definition 4 (PP-Rules). A pair r, f is called pp-rule, if r L x — 

R is a rule with strict transition preserving morphisms u, v and a place preserv- 
ing morphism f L — R with f —u v. 

Definition 5 (TG- Rules). A pair r, f is called tg-rule, if r L x ~ 

R is a rule with strict transition preserving morphisms u, v and a transition 
gluing morphism f L — R with f —u v. 

Example 2 (Rules in Example). x m 



X m 

m m 

m m 

Definition 6 (Safety Property, Formulas, Translations). 

1. The set of static formulas — is given inductively: For X a, p — A — P 

we have the atoms X a, p . Furthermore (ipi — —Lpi , and 

(ifl ,ip2 TI-T 2 )■ 

The validity of formulas is given w. r. t. the marking of a net. Let m — 
A — P he a marking of N then: m — n X a, p iff X a, p — m, and 
m-N ~Ti iff - m - N , and m - n ~V2 iff m - n ~ m - n T 2 ■ 

2. Let ip be a static formula over N . Then E\ip is a safety property. The 

safety property holds in N under m iff p holds in all states reachable 

from m: 

m — N G\p -mi — [m— m — n P 

For the initial marking m we also write N — E\p instead of fh — n G\p. 

3. The translation —f of formulas over Ni along a morphism f fs,fA, 
fp, /t .^1 — XI 2 to formulas over N 2 is given for atoms by 

-f X a, p X fA a ,fp p 

The translation of formulas is given recursively by — / —p — -/ p , —f p\ — 

P2. —f Pi f P 2 and —f Hp □— / p . 




Definition 7 (Safety Preserving Morphism). A morphism f Ni — N2 is 

called safety preserving, iff for all safety properties we have Ni — 'Orp — 
N2 f . 



Definition 8 (Safety Preserving Rule and Transformation). Given a rule 
r L ^ K — R in an HLR system and an arbitrary morphism f L — R. 
The pair r, f is a safety preserving rule, iff 

1 . f is a safety preserving morphism 

2 . given a net Ni, and an occurrence g\ L — N\, the direct transformation 
Ni — N2 yields a safety preserving morphism f Ni — N2- 

(?",/) 

We denote the direct transformation by Ni — N2 and call it safety preserving 
transformation, short sp-transformation. 
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Theorem 1 (PP-Rules are Safety Preserving [PGE98]). 



Proof k 
m 

m k 



m 

m 



Theorem 2 (TG- Rules are Safety Preserving). 
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Definition 9 (Safety Introducing). Given a rule r L ^ K — R and a 

safety property GiLp over R s. t. R — 'Orp. If o R — N 2 is safety preseving for 
all transformations Ni — N 2 , r is called safety introducing rule. 

Definition 10 (SI- Rule). A rule of the form r —< R is called si-rule. 



Example 3 (SI-Rule in Example). 

□ a, patient at ward d, ward documents 



Theorem 3 (SI- Rules are Safety Introducing and Preserving). 

Proof. k N 

R o R — N R j 

mm m 

m m — R m 
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Main Conceptual Result 11 (Stepwise Development of Safe Models). 

The concept of introducing safety properties (see Definition 10) enables develop- 
ment of an AHL net system hand-in-hand with its safety properties. The safety 
property has to be proven only once for the right-hand side of the rule. Subsequent 
refinement by si-rules, pp-rules, or tg-rules does not only preserve the explicitly 
introduced, but also all implicit safety properties (see Theorems 1, 2, and 3). 
Hence, employing these kinds of rules in the development of a system supports 
the development of safe models. 

4 Conclusion 
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Definition 12 (Rules and Transformations). A 1 r L - - K — R in C 

consists of the objects L, K and R, called left-hand side, interface (or gluing object) 
and right-hand side respectively, and two 



morphisms K — L and K — ^ R with both morphisms 
u,v — M, a distinguished class of morphisms in C. 

Civen a rule r L K — R a 

G — H , from an object G to an object H is given 
by two pushout diagrams 
(1) and (2) in the category C. The morphisms L G and R H are called 
occurrences of L in G and R in H, respectively. By an occurrence of rule r L — 
K — R in a structure G we mean an occurrence of the left-hand side L in G. 





A G H , short transformation, between objects G and 

H means G is isomorphic to H or there is a sequence of n direct transformations: 
G G G Gn H. 



Definition 13 (High-Level Replacement System). Given a category C together 
with a distinguished class of morphisms A4 then C,A4 is called a HLR-category if 
C,M satisfies the HLR- Conditions (see [EGP99]). 

11 1 

1 Q 

1 



Definition 14 {Q: Refinement Morphism [Pad99]). Let QCat be a category, so 
that C is a subcategory C QCat and Q a class of morphisms in QCat. 

1. The morphisms in Q are called Q-morphisms, or refinement morphisms. 

2. Then we have the following Q-conditions: 

Closedness: Q has to be closed under composition. 

Preservation of Pushouts: The inclusion functor I C QCat preserves 
pushouts, that is, given G — D ^ — B a pushout of B A — G in 

C, then I C I D I B is a pushout of I B I A I G in 

QCat. 

Inheritance of Q-morphisms under Pushouts: The class Q in QCat is 

closed under the construction of pushouts in QCat, that is, given 

C — D B a pushout of B A— G in QCat, then f Q f' 

Q. 

Inheritance of Q-morphisms under Coproducts: The class Q in QCat is 

f 

closed under the construction of coproducts in QCat, that is, for A — B 

j! 

and A' — B' we have f,f'Q f f' Q provided the coproduct 

A A' B B' of f and f' exists in QCat. 

3. A Q-rule r, q is given by a rule r L K — R in C and a Q-morphism 
q L R, so that K - L- R K - R in QCat. 

1 Q 1 

Lemma 1 (Q- Transformations [Pad99]). Let C, QCat, Q , and I C QCat 

satisfy the Q-conditions. Given a Q-rule r, q and a transformation G ^ H in C 

q£Q 

defined by the pushouts (1) and (2), then there is a 
unique q' Q, such that q' o ci C 2 and q' o g^ ga°q 
in QCat. The transformation G H,q' G H , 

or short G ^ ^ H , is called Q-transformation. R 

H G is pushout of G L - R m QCat. 

q es 
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B Algebraic High-Level Net Sy terns 

Definition 15 (Category CMON of Free Commutative Monoids). Let P be a 

set. Then -P®, A) called the free commutative monoid generated by P, s.t. for all 
u, V, w P® the following equations hold: 

— A P® 

— V \ X V V, 

— U V W U V w 

— V W W V 

Elements w of the free commutative monoid P® are called linear sums. They can 
be represented as w Ylpep P with coefficients Xp N and p P. They can be 
considered as multisets. 

Free commutative Monoids together with set-based monoid homomorphism define 
the category CMON. 



Definition 16 (Operations of Free Commutative Monoids). Free commutative 
monoids imply the operations , ©, and on linear sums. These are the obvious 
addition, subtraction and comparison of coefficients on linear sums. 

Let Ml, M2 P® with Ml X^pgpAp p and M2 SpgpAp p, then 

Ml M2 , if p P Xp Xp 

Ml M2 , if p P Xp Xp 

Ml M2 Y^pizp Ap Ap p 

Ml 0 M2 Spgp Ap — Ap p, if Ml M2 

Lemma 2 (Induced Functions of Place Vector). Letm A P ® Then we have 
m P A® . Similarily, let m Top X P ®. Then we have m P Tqp X . 

Definition 17 (Pre- and Post Set). Given an AHL net system N SPEC, A, P, 
T, pre, post, cond,fh then we define 

p post t p t Top X T® 

ter 

and 

p ^^pre t p t Top X T ® 

tGT 



Definition 18 (Restrictions of Place Vector). Given m A P ® and let P' 

P, then there is mi A p' ® and m2 A p p' ® such that m mi m2. 
We define m^p mi. 

Moreover there are two important special cases: 

1. P' p denoted with m|p 

2. P' fp Po for some function fp Po P, denoted with m^fp 




Lemma 3 (Restrictions are Compatible with Monoid-Operations). Let P' 

P and m A P ® and p Pi . Then we have 

m m' |p m|p mjp 

niQm' |p m|p ©mjp 

m m' m\p mjp 

/m m I/p /m m 

Im W-ll/p "l2|/p(p) p m 2 fp p 
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Abstract. The B method has been successfully used to specify many 
industrial applications by refinement. Previously, we proposed enriching 
the B event systems by formulating its dynamic properties in LTL. This 
enables us to combine model-checking with theorem-proving verihcation 
technologies. The model-checking of LTL formulae necessitates that the 
B event system semantics is a transition system. In this paper, we express 
the refinement relation by a relationship between transition systems. A 
result of our study shows that this relation is a special kind of simula- 
tion allowing us to exploit the partition of the reachable state space for 
a modular verification of LTL formulae. The results of the paper allow 
us to build a bridge between the above view of the refinement and the 
notions of observability characterized as simulation relations by Milner, 
van Glabbeek, Bloom and others. The refinement relation we define in 
the paper is a ready-simulation generalization which is similar to the re- 
fusal simulation of Ulidowsky. The way the relation is defined allows us 
to obtain a compositionality result w.r.t. parallel composition operation. 

For complex systems, it is important in practice to associate a design by 
refinement with a design by a parallel composition of their components. 
This refinement relation has two main applications: 

— it allows the splitting of the refined transition system into modules; 

— it allows the construction of complex systems by a parallel compo- 
sition of components. 

It makes sense to qualify the refinement relation as being modular. 
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2 Preliminaries 
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Proposition 1. For any relation from a set \ to a set 2 ( 
we have: 



— For any 1, 2 subsets of 2, 

— For any 2 subsets of i, 
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Proposition 2. Let be 



. Then 
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Definition 2. (Galois connections) Let 1 and 2 be two sets of states. A 
connection from to is a pair of monotonic functions 7 , where 
and 7 , such that Si 7 o-nd 7 S2 . 
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Proposition 3. (Connections generated by a binary relation on states) 

If 1 2, then the pair is a connection from to , 

and is a connection from to . 



3 Behavioral Semantics of Systems Derived from the B 
Design 
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4 Modular Refinement Relation 
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4.1 Modular Refinement as State Space Partition 
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Definition 3. (Glued states) The state 2 2 1 to i i, written 

as 2 1 , 'iff 2 2 1 • 




Definition 4. (Equivalence class name) Let be an equivalence class of 
2 The state 1 i is the name of iff, for a state 2 > 'we have 

2 1 • 



4.2 Modular Refinement as a Relation 
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Prom a Refined Transition System to One of Its Abstraction 
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Definitions. Let 1 ( 1 A 1 — 1 x— and 2 ( 2 A — 2 2— &e 

respectively a transition system and its refinement. Let be in A 1 . The relation 
— 2— 1 is defined as the greatest binary relation included into and satisfying 

the following clauses: 



1 . (strict transition refinement) 2 1—2—22” — i s.t. 

1 ~ 2 1 

2 . (stuttering transition refinement) 

r _ a _ a__ _ 

2 1— 2— 22— 22 — — i^-*-i — ii— 2 1—2 1 
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Prom an Abstract Transition System to One of Its Refinement 

Definition 6 . Let 1 ( 1 A 1 — 1 x— and 2 ( 2 A — 2 2— &e 

respectively a transition system and its refinement. Let he in A 1 . The relation 
— 1 — 2 is the greatest binary relation included into and satisfying the 

following clause: 
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Definition 7 . ( Let 2 { 2 A 2 and 1 { \ A i i be 
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Theorem 1 . Let rj be the relation between the two transition systems 2 
( 2 ^ It 22 and 1 { I A I 1 1 • Then 2 r; i- 
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Definition 9 . Let 1 { \ A i 11 and 2 ( 2 ^ ir 2 2 be 

respectively a transition system and its refinement. Let be in A 1 . The relation 
1 2 is the greatest binary relation included into and satisfying the 

following clause: 

(readies) 1 1 f 1 2 readies 1 ( readies 2 

92 s.t. 9i?92 



Theorem 3 . Definition 6 and Definition 9 are equivalent. 
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6 Compositionality of the Modular Refinement 
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Definition 10. (Parallel composition) Let i { i A i i i and j 

{ j A j j j be two transition systems. The parallel composition of i and 
j is i i ( At where is the set of the ~ ( i and 

~ j), A is the union of A j and A j, is the product of i and j . Let 

A T, for , the transition relation is defined by combining 

individual actions in parallel as follows. 
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9 Conclusion and Related Works 
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Abstract. Existing software configuration management systems em- 
body a wide variety of policies for how artifacts can evolve. New policies 
continue to be introduced. Without a clean separation of configuration 
management policies from configuration management mechanisms, it is 
difficult to understand the policies as well as difhcult to reason about 
how they relate. We introduce a formal foundation for specifying config- 
uration management policies by viewing the policies in terms of graph 
transformation systems. Not only are we able to precisely capture the se- 
mantics of individual policies, we can, for the first time, describe formal 
properties of the relationship between policies. 
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fra, fp 
G,ta ^ 
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H,tH with d Pi full ... Pn/rUn in Der G there is a deriva- 
tion f d f^Q G, ta f^Q H, tn in Der G , where f d 

fp Pi /Itg ■ ■ ■ fp Pn /Itg ■ Moreover, f^Q f d G, to 

fpG M,tn d G,tc => H,tn • 



t y 

i t t 1 ti it 
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1 context iti 
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t i G 
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i t i t t 
i ti t i 

i 1 1 li ti 



t i G’ t 

It lit 
it t t 
1 i t 



Definition 4 (Application Gonditions). 

— An li ti iti for a match m L ^ G is a total graph morphism 

Ci L > Li . 

— A iti application condition Ci is satisfied by m if there exists a (total) 
graph morphism n Li ^ G such that no Ci m. 

— A ti application condition Ci is satisfied by m if there is no (total) 

graph morphism n Li ^ G such that no a m. 

— A iti 1 1 is a rule p with a set of application conditions Gond and a 

derivation p / m G,tc ^ H,tH takes place only if the match m satisfies 
every condition in Gond. 
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Formalization of CM Policies 
















lly li y t 




ti 






i 






t 


t i 


ti t 




checked out 


i 1 




i 


ti 




check in 


ti t 


t 




i 


1 i 


ti 




t 


i t 


i 




















t li y i 


i 


i 




t 


t 




i 






1 t t 




1 i 


y 


1 


i 






i 




iti i i 


lly 


li 


y 


1 


t 


t 




current 




i t Iti 


y i 




1 






i 




t 


t 


y t it t 11 


t 


1 


t 




i y t 


it 


y 


1 




t i t 


1 




i 


i 


i t 


ti 




i t 




i t i ill t 1 


i 






t 






ti 


i t 


i 


1 t i 




t 






t t t 









Definition 5 (Policy). A policy A is a triple T, Pos, Neg where 



— T G, TG is the type of the policy consisting of a set G of labels and a 
type graph TG 
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— Pos is a C,TG -graph transformation system 

— Neg is a set of C,TG -graphs and G,TG -graph morphisms 

The three components are denoted by T A , Pos A and Neg A , respectively 
and GPos A denotes the set of graphs generated by Pos A (starting from the 
empty graph). 
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Pos REV 1 
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t i ti 11 ti 
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Definition 6. A policy A is t if G Pos A satisfies Neg A , i.e., if its 

rules cannot generate a graph containing an unwanted graph. 

A coherent policy A is \ if any graph not in GPos A is rejected by 
Neg A , i.e., if the positive and negative parts of A describe all the graphs over 
T A C,TG 



Example 2. t 
t i t i 
li y i t 
1 y i i 
i i i y t 
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N^N^E 
i tit 



It t t t t li y REV i i 

1 tit -tti tt titi 
- t il t ly y t i t 
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11 t t t Neg A t t it 1 H^H^H 

t t t t - i li i y 

i i t t Pos Neg i 1 
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t i ti i ti li y OPT i 11 y i 
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ly t t t 1 y t ti i ti li y il t 

t t i GPos PES C GPos OPT t y t 

y OPT i 1 t y PES i 1 it ti 1 i t 1 t 
t It it y OPT i it ti liz y t 

ti ti 

Definition 7 (Subsumption). A policy A a policy B of the same 

type C,TG if GPos B C GPos A and Neg A C Neg B . 



i liz y i t li i 

Definition 8 (Policy Morphism). A policy morphism f A ^ B between 
policies A and B is a triple fr,fp,fN where 

~ fr fc,fTG Ga,TGa Cb,TGb is a pair consisting of a total 
function and a total (untyped) graph morphism 
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— fp Pos A — > Pos B and /at Neg B ^ Neg A are tgts-morphisms as 
in Def.3 with respect to the type morphism fp- 

Remark 1. tt- i /Ariit tt liy^ t tl tilt 
ttliyi? t ttyi ily tt- i 

/p i i t t t t t ty i i y /t li y -B 11 1 1 
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A ^ B t B A ii Itt fp 

It t rules tt 11 it yt ytt- ^ fp 

Pos A — > Pos B y t GPos A C GPos B 

11 y 1 ily t 1 t 

1 t iti ti fc 1 fpG t t - 

1 fp /at 11 1 ti it t 11 titi 1 

t 1 t 11 1 It 

Theorem 1. The category POLIGY of policies and policy morphisms is closed 
under finite colimits 

t iti ly t t t 11 y i Aq ^ Ai — *■ ^2 

t t li y y t 1 t t t iti 1 

t 11 t ti i li y t t 

t t i t 11 i t til 

t t t t ti it 3 



4 Relationships Between Policies 
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Uy 

Definition 9 (Negative Strategies). For sets of morphisms Neg A and 
Neg B , define 
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— CA Neg A ,Neg B Neg A U Neg B 

— CD Neg A , Neg B {Na Nb ^ Ea Eg Na ^ Ea G 

Neg A ,Nb Eb € Neg B }\J{Ha EIb Ha G Neg A ,Hb G Neg B } 

— DA Neg A ,Neg B Neg A n Neg B 



Interpretation 
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Definition 10 (Positive Strategies). Given graph transformation systems 
Pos A and Pos B , define 



- CA Pos A , Pos B 

- CD Pos A , Pos B 

- DA Pos A , Pos B 



Pos A n Pos B 

{PA Pb pa G Pos A ,pB G Pos B } 
Pos A U Pos B 



Interpretation 
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Definition 11. Given policies A and B, the combination of A and B with 
strategies X and Y is denoted by X,Y A, B and is the policy C where 
Pos C X Pos A , Pos B and 
Neg C Y Neg A , Neg B 
for X,Y G {DA,CD,CA} 

t It i i H i i t i t H ti t 

iti 



Proposition 2. If A and B are policies such that there exists a policy morphism 
from A to B, then 

1. DA, DA A,B B 

2. CA,CA A,B A 
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Proposition 3. 1. If A and B are coherent, then C CA,CA A,B is co- 

herent 

2. There exist coherent policies A and B such that D DA, DA A, B is not 
coherent. 



Proof. 
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Proposition 4. If A and B are coherent, then CA, X A, B is coherent for 
any X G {C A, CD, DA} 



Proposition 5. (a) For any X G {CA,CD,DA}, if X,CA A,B is coherent, 
then so are X,CD A,B and X,DA A,B 

(b) There exist coherent policies A, B, P, and Q such that CD, DA P,Q and 
CD, CD A, B are not coherent. 

i 1 i tit i t il 

Hi it li y t t 

Theorem 2. If DA,CA A,B is coherent, then X,Y A,B is coherent for 
any X,Y € {C A, CD, DA} 

Example 3. t 

it li y VAR t ty Ty Tr t 

li y REV t tl t tit iit it 
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Theorem 3. Let A and B he coherent policies over types Ta and Tb, respec- 
tively, and Ja T — > Ta, Jb T ^ Tb type morphisms with f T ^ Ta t Tb- 
Denote by A* and B* the policies A and B, respectively, viewed over the type 
Ta tTb- The policy DA,CA A*,B* is coherent if and only if the policy 
DA A*,B* ,NEG is coherent, where 
NEG {n € Neg A* U Neg B* f^ /< n n}. 
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Definition 12. Policies A and B 
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Proposition 6. Policies A and B are 


equivalent if and only if A subsumes B 


and B subsumes A. 














Theorem 4. Given closed policies A and B, 
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A, B is coherent if and 
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5 Conclusion 
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Agents 
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Abstract. The mobile agent technology is emerging as a useful new way 
of building large distributed systems. The advantages of mobile agents 
over the traditional client-server model are mainly non-functional. We 
believe that one of the reasons preventing the wide-spread use of mobile 
agents is that non-functional properties are not easily grasped by system 
designers. Selecting the right interactions to implement complex services 
is therefore a tricky task. In this paper, we tackle this problem by con- 
sidering efficiency and security criteria. We propose a language-based 
framework for the specihcation and implementation of complex services 
built from interactions with primitive services. Mobile agents, RPC, re- 
mote evaluation, or any combination of these forms of interaction can 
be expressed in this framework. We show how to analyze (i.e. assess and 
compare) complex service implementations with respect to efficiency and 
security properties. This analysis provides guidelines to service design- 
ers, enabling them to systematically select and combine different types 
of protocols for the effective realization of interactions with primitive 
services. 



1 Introduction 
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^ In our context, we consider them both as degenerate forms of mobile agents. Remote 
evaluations execute remotely the code on a single server. A Rpc amounts to sending 
a request (not a code) to a primitive service. 



T. Maibaum (Ed.): EASE 2000, LNCS 1783, pp. 319-333, 2000. 
(c) Springer- Verlag Berlin Heidelberg 2000 




320 Pascal Fradet, Valerie Issarny, and Siegfried Rouvrais 



h 



h 



h h 



h h h 

Rpc 

h h 

h 

h 

h 

h h 

h 



Pda . 
h 
h 

h 

. h h 



h 

h h h 



h h 



h 



h h 

Rpc 



h 



h 



h 



h 



h 

h 

h h 




h h 



h 



h h 



h 



h 



h 

h h h h 



h h 
h 



h 

h h h 

fl h 

h h h 



h 



2 Functional Models of Interactions 
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^ Actually, even if some migrations could be deduced from the locations of base ser- 
vices, the go functions are needed to specify where treatments are to be executed. 
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® Numerical values are easy to normalize and compare whereas symbolic values are 
more generic and represent more faithfully the reality. Both fit in our framework and 
we do not dwell on this issue any further in this paper. 
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^ When there is no knowledge on the security of a place, the lowest security level 
should be taken. 
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1 Introduction 

In the following we will describe some practical experience on synthesizing pro- 
grams for the LEGO® RCX’’'“ system. The synthesis is based partly on an exist- 
ing simple program and partly on an automaton generated by the tool Mona [7]. 

Writing control programs can often be an error prone task, especially if a 
number of special cases must be taken into account. Time is often spent on 
handling special case or failure situations rather than solving the actual problem 
at hand. A number of different methods and tools have been developed to ease 
this task. One well known method is based on a control automaton running in 
parallel with the actual program [12, 13]. The automaton controls the input and 
output events of the program. This is a way of restricting the sequences of I/O 
actions occurring. 

The automata controlling the I/O actions can be specified in different ways, 
e.g. by specifying it directly in some suitable notation, or by a logical formula. 
We have chosen the latter approach. There are various logics which could be used 
as specification language. We have chosen to use monadic second order logic over 
strings (M2L) [2] for a number of reasons. First of all M2L has a number of nice 
properties such as being expressive and succinct. For instance, having second 
order quantification M2L is more expressive than LTL. Furthermore, there are 
succinct M2L-formulae of size n which have minimal corresponding automata 
of non-elementary size. Secondly, the tool Mona [7] implements a translation 
from M2L formulae to minimal deterministic automata (MDFA) accepting the 
language specified by the formula. The automata generated do not contain any 
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acceptance condition for infinite executions so we will only be considering safety 
properties. 

The method we study here is a variation of classical synthesis as described 
in e.g. [10, 12], in that the method is partly based on an existing control pro- 
gram. The aim of the synthesis described here is to restrict the behavior of an 
existing (hopefully very simple) control program such that it satisfies certain 
given properties. The executions of the existing control program are restricted 
by the control automaton having I/O events as alphabet. These events define 
the interface between the existing control program and the specification. 

For studying the method we will look at a control program for a moving crane. 
We have implemented the method for this example in the LEGO® RCX'''“ sys- 
tem [9]. Using the LEGO® RGX™ system is interesting for at least two reasons. 
First of all the environment of the RGX'''“ system and especially the program- 
ming language is quite restricted, so it is not obvious that implementing the 
method is feasible at all. Secondly, using the LEGO® RGX'''“ system one can 
build actual physical systems for testing the control programs. We have built 
the crane and used it with different control programs. 

The language running on the LEGO® RGX'''“ brick (RGX'''“ language) is an 
assembly-like language with a few high level features, like a notion of task or 
process. Programs are written on a PG and downloaded to the RGX'''“ brick 
where they are interpreted. 



1.1 Related Work 

The use of finite state automata for controlling systems is not novel. Ramadge 
and Wonham [12] give a survey of classic results. 

The method used in this paper has been used successfully in <bigwig> [13], 
a tool for specifying and generating interactive Web services. Our method for 
control synthesis is used as an integral part of <bigwig> to define safety con- 
straints. In fact, via use of a powerful macro mechanism [1] the method has been 
used to extend the Web programming language in <bigwig> with concepts and 
primitives for concurrency control, such as, semaphores and monitors. 

1.2 Outline of the Paper 

In the following section we will outline the method. A short presentation of the 
LEGO® system is given in Section 3. In Section 4 the crane example is presented. 
The logic-based specification language is presented in Section 5, and the merge 
of automata with the RGX'''“ code in Section 6. Finally, Section 7 rounds off with 
conclusions, and suggestions for future work. 



2 Outline of the Method 



The two main components of the synthesis is a basic control program and an 
automaton. From these two components we generate a control program which 
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is ready for use. We do not have any special requirements to what a control 
program is, like no side effects, since in our case the control program is the only 
program running on the RCX'''''^ brick. The interface between the two components 
is a predefined set of I/O actions. This will typically be all commands in the 
program for reading sensors or manipulating actuators. 

Given a basic control program and an implementation of the automaton we 
merge these. Each instruction in the basic control program using one of the I/O 
actions is transformed to a sequence of instructions first calling the automaton 
and based on the response from the automaton performing the action or not. 
Section 6.3 will discuss different approaches to what should happen, when a 
given action is not allowed by the automaton. 

Since the automaton is invoked only when the basic control program is about 
to make an I/O action, it can only restrict the possible I/O behaviors of the 
control program, not add new I/O actions. Only looking at sequences of I/O 
actions the basic control program must therefore be able to generate all se- 
quences present in the solution. Since the automaton will prune away unwanted 
sequences, the basic control program might also generate unwanted sequences. 
The basic control program should not implement any kind of priority scheme, 
unless one is sure that combining this with the safety specification will not lead 
to deadlocks. 

The hope is that writing such basic control programs should be a simple task. 
In general the basic control program could be one always being able to read any 
sensor and give any command to the actuators. This amounts to generating the 
star operation of the input alphabet. However, there will often be a correspon- 
dence between input and output which it would be natural to have in a basic 
the control program. This is the case in the example shown later. 

One could see the basic control program as implementing the method for 
controlling the sequences of I/O actions and the automaton defining the allowed 
policy for these. This suggests that with one implementation of a basic control 
program it is possible to test different specifications or strategies (policies) only 
by changing the control automaton. Therefore, a fast (automatic) way of getting 
an implementation of an automaton from a specification and merging this with 
the control program allows for testing different specifications fast. 

3 The LEGO® System 

The studies we have conducted are based on the LEGO® RGX'''“ system and the 
associated RGX'''“ language. The language is an assembly like language with some 
high level concepts like concurrent tasks. The language is restricted in a number 
of ways, e.g. it is possible to address only 32 integer variables and allows only ten 
tasks in a program. Furthermore, one cannot use symbolic names in programs. 
However, we have not encountered problems with the mentioned restrictions 
during our experiments. 

A small operating system is running on the RGX''''^ with processes for handling 
I/O and one process running an interpreter for the RGX'''“ language. The RGX'''“ 
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brick has three output ports (for motors and lights) and three input ports. Four 
kinds of sensors for the input ports are supplied by LEGO®: touch, temperature, 
rotation, and light. 



3.1 The RCX™ Language 

A program consists of a collection of at most ten tasks. There is no special way 
to communicate between tasks but all variables are shared, providing a way of 
communication. A task can start another task with the command StartTask(i) 
and stop it with the command StopTask(i). Starting a task means restarting 
it from the beginning. That is, there is no command for resuming the execution 
of a task nor spawning an extra “instance” of a task. 

The language has some commands for controlling the actuators, the main 
ones being On(li) and Off(li) where li is a list of ports. The commands 
SetFwd(li) and SetRwd(li) sets the direction of the ports in li to forward and 
reverse respectively. There are also a number of instructions for manipulating 
variables. All of these take three integer arguments. The first argument specifies 
the target variable, the second the type of the source, and the third the source. 
The most important types of sources are: variables (the third argument is then 
the number of the variable), constants (the third argument is then the value), and 
sensor readings (the third argument is then the number of the sensor). These 
types of sources can be used in the instruction SetVarCi, j ,k) for assigning 
a value to a variable. In the instructions for calculating like SumVarCi, j ,k), 
SubVarCi, j ,k), and MulVarCi, j ,k) sensor readings are not allowed. 

Loops can be defined in two ways, either by the LoopCj ,k) instruction or by 
the WhileCj ,k,l,m,n) instruction. The arguments of the Loop indicates how 
many times the body should be iterated in the same way as the source of the 
instructions for calculating. The While loop is iterated as long as the condition 
specified by the arguments is satisfied. The first two and last two arguments 
specify the sources of a comparison as in an assignment and 1 specifies a relation 
from the set {=, <, >, yf}. 

There is also a conditional. If (j ,k,l,m,n), with the condition specified as 
in the While construct and an Else branch can be specified as well. 

One can block a task for a given time using the Wait ( j ,k) statement. When 
the specified time has passed, execution of the task is resumed. 

During execution a task is either enabled or blocked. A task can be blocked 
by a StopTask(i) instruction, by a Wait(j,k) instruction, or by finishing its 
execution (reaching the end of the code). Initially only task zero is enabled. The 
enabled tasks are executed in a round robin fashion, where each task executes 
one instruction and then leaves control for the next task. 

The statements presented above constitute the part of the RCX'^'^ language 
which we have used for implementing control automata. 
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4 Example 

As an example we will look at a crane which we will program in the RCX'''“ 
language. We have built the crane and tested it with different control programs. 
The crane is run by three motors connected to the RCX'''“. One motor is driving 
the wheels, one is turning the turret around, and one is moving the hook up 
and down. The input for the three motors are three touch sensors, which is all 
the RCX^“ brick has room for. This means we can only turn motors on and off. 
Therefore the crane alternates between moving forward and backward each time 
the motor is turned on. The direction of turret and the hook is controlled in a 
similar way. 

A very basic control program for the crane could consist of four tasks. One 
task for setting up the sensors and motors, and starting the other tasks. For 
each of the three inputs, one task for monitoring input and controlling the motor 
correspondingly. Task 1 for monitoring sensor 0 would then be 

BeginOfTask 1 

Loop 2, 0 ’An infinite loop 

SetFwd "0" ’Set direction of motor 0 to forward 

SetVar 1, SENSOR, 0 ’Varl := SensorO 

While VAR, 1, 3, CONST, 1 ’While Varl != 1 
SetVar 1, SENSOR, 0 
EndWhile 

On "0" ’Start motor 0 

Wait CONST, 100 ’Wait 

SetVar 1, SENSOR, 0 ’Varl := SensorO 

While VAR, 1, 3, CONST, 1 ’While Varl != 1 

SetVar 1, SENSOR, 0 
EndWhile 

Off "0" ’Stop motor 0 

Wait CONST, 100 ’Wait 

. . . repeat the code replacing SetFwd "0" with SetRwd "0" . . . 

EndLoop 

EndOfTask 

The Wait statements ensures that one touch of the sensor is not read as two 
touches. We could of course have tested for this but for our example this will 
do. The two other tasks for controlling the remaining two motors look similar, 
only the numbers of variables, sensors and motors are different. 

For the purpose of illustrating the presented method we choose to place the 
following constraints on the behavior of the crane. First of all we only want one 
thing happening at a time, so we will not allow for two motors to be turned 
on at the same time. Pressing the touch sensor could now be seen as a request 
which the control program may grant (and start the motor) when all the motors 
are stopped. Moreover, we want that moving the hook has higher priority than 
the wheels and the turret. Requests from the other two are handled in order of 
arrival. The first constraint on the behavior is basically mutual exclusion which 
is nontrivial to implement in the RCX'''“ language (this is an integrated part of 
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the implementation of the automata-based approach described in Section 6). On 
top of this we have a mixed priority and queue scheme. 



5 Logic-Based Specifications 

Basically we could keep the initial simple control program if we had a way of 
pruning out some unwanted executions. To be able to implement the constraints 
we have to change the initial control program slightly. This is done by considering 
touching a sensor as a request. The motor can be turned on when the request 
is accepted. Even with these changes the program is still a simple to write. 
Execution of the program gives rise to a sequence of events. In our case we will 
consider input (requests), and two kinds of output (start and stop motor) as 
events. We then implement the automaton accepting the language over these 
events satisfying the introduced constraints. With this approach we can thus 
keep the control program simple. 

Traditionally, control languages are described by automata which are in some 
cases a good formalism to work with. However, having experience in using logic 
for specifying properties, we will take that approach here. In this section we 
describe the use of a logic formalism from which we can automatically generate 
automata. 



5.1 Terminology 

An automaton is a structure A = (Q, g™, S, F), where Q is a set of states with 
initial state g“ G Q, S is a, finite set of events, Q x E x Q is the transition 
relation, and F C Q the set of acceptance states. We shall use qi q2 to denote 
(gi,cr, 52) A sequence w = agai . . G A is said to be accepted by 

the automaton A if there exists a run of A which reads the sequence w and 
ends up in an accepting state q. So we have gi, . . . , g„_i G Q and q G F, such 
that g“ ^ gi ^ . . . g„_i q. We shall denote by L{A) the language 
recognized by an automaton, that is, L{A) = {w G E \ A accepts w }. 

In order to be able to define the notion of a legal control language, one 
partitions the event set E into uncontrollable and controllable events: E = U 
Ec- The controllable events can be disabled by the control automaton at any 
time, whereas the uncontrollable ones are performed autonomously by the system 
without any possible interference by the control automaton, which merely has 
to accept the fact that the particular uncontrollable event has occurred. Thus a 
control language must in some sense, which is defined precisely below, respect 
the uncontrollableness of certain events. Furthermore, since our method only 
allows restrictions concerning safety properties, it does not make sense to have 
non-prefix-closed languages as control languages. That is, we define the notion 
of control language as follows. 
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Let pre{L) denote the prefix closure of a language L, and let unc{L) denote 
closure of L under concatenation of uncontrollable events. That is, let 

pre{L) = {v € S \ G S : vw G L} and 
unc{L) = { vw G S \ v G L A w G }. 

A language, L over E = U Ec is called a control language if it satisfies the 
two properties pre{L) = L and unc{L) = L. 

When using deterministic finite state automata to specify sets of sequences, 
checking for prefix closedness is easy. One just has to make sure that all tran- 
sitions from non-accepting states go to non-accepting states. Similarly, checking 
closure under concatenation of uncontrollable events is straightforward for de- 
terministic automata. 

What is new here, in comparison to the use of our method in [13], apart from 
the new domain of LEGO® RCX'''“ robots, is the partition into controllable and 
uncontrollable events and the resulting additional restrictions and computations. 



5.2 Specification Logic 

It would be nice if instead of converting the informal requirement in Section 4 
into an automaton, one could write it formally in a specification formalism closer 
to natural language. That is, we would like to be able to write something like 
the following. 

— Only one motor can be turned on at a time; 

— If the wheels get turned on, then the hook must not be requesting and the 
wheels must have been the first to make a request; and 

— If the turret gets turned on, then the hook must not be requesting and the 
wheels must have been the first to make a request. 

We therefore turn to a formalism that is as expressive as finite state automata 
and yet still allows for separation of the declaratively specified requirements (pre- 
viously our control automaton) and the operational part of the control program 
(the existing RCX'''“ program). 

Experience has shown that logic is a suitable specification formalism for con- 
trol languages. For the purpose of defining controllers for LEGO® RGX'''“ robots, 
we have chosen to use M2L. One might argue in favor of other specification for- 
malisms such as high-level Petri Nets [6] or Message Sequence Gharts [1 1] . Being 
a logic formalism, however, M2L has the advantage that specifications can be 
developed iteratively, that is, one can easily add, delete, and modify parts of a 
specification. It also has a readable textual format. Moreover, the formalism in 
use should be simple enough that a runtime checker, such as an automaton, can 
actually be calculated and downloaded to the RGX'''“ brick. Thus, M2L is power- 
ful and yet just simple enough to actually subject it to automated computation. 

Experience in using M2L as a language for defining control requirements 
has shown that only the first-order fraction of the logic is used in practice [1, 
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13]. We shall thus consider only first order quantifications, though second-order 
quantifications could be added at no extra cost. 

The abstract syntax of the logic is given by the following grammar: 

(j) '■'■= 3p : 4> \ \/p : 4> I ~^(j> \ (j> A 4> \ (j> \/ 4> \ (j> ^ (j> \ a{t) \ t <t 
t-.-.= p\ t+l 

That is, M2L has the constructs: universal and existential quantifications over 
first order variables (ranging over positions in the sequence of events), standard 
boolean connectives such as negation, conjunction, disjunction, and implication, 
and basic formulae, <j{t), to test whether an event a can be found at position t, 
and t < t , to test whether position t is before position t . It also has operations 
on terms, such as, given a position t one can point out its successor (t -|- 1), and 
simple term variables (p). 

A formula (j) in M2L over the event set S will - when interpreted over a 
finite sequence of events w - either evaluate to true or to false and we shall 
write this as w |= (/) or w ^ respectively. The language associated with (p is 

The language associated with an M2L formula is 
guaranteed to be regular. In fact, it has been known since the sixties that M2L 
characterizes regularity [2, 4]. 

The Mona tool implements the constructive proof of the fact that for each 
M2L formula there is a minimal deterministic finite state automaton accepting 
the language of the formula. That is, Mona translates a particular M2L formulae, 
(j), into its corresponding minimal deterministic finite state automata (MDFA), 
A, such that L(c/>) = L(A). 

Example 1. Let S = {a, 6, c}. The M2L formula to left 

Vp,p : {p < p A a{p) A a{p )) 

3p : p < p < p A b{p ) 

is true for sequences in which any two occurrences of a will have an occurrence 
of b in between. Using Mona, one can compute the automaton corresponding to 
the formula above. The resulting automaton appears to the right. 




Example 2. With this logic-based specification language in place, we can write 
a specification of the requirements given in the example. The logic-based spec- 
ification looks quite complex at first. However, because of it’s modular struc- 
ture we find it easier to handle than the automaton. The basic formulae for 
the elements of the alphabet are reql(t), req2(t), req3(t), turnonl(t), 
turnon2(t), turnon3(t), turnoffl(t), turnoff2(t), and turnoffl(t). The 
first three are uncontrollable events of the alphabet and the rest are controllable 
events of the alphabet. A predicate is true if the event at position t is the men- 
tioned event. Using these basic predicates we can define some basic predicates 
like all motors are stopped by: 
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ofFl(i) = (Vi : t <t ^ ^turnonl(i )) V 
(Vi : (i < i A turnonl(i )) 

3i :t <t At < i A turnoff l(i )) 

Similarly, we define predicates off2(t) and off3(t) and using these we can 
define a predicate, alloff(t), specifying that all the motors are turned off. 

alloff(i) = offl(i) A ofT2(i) A off3(i) 

We can specify that motor 1 has been requested to be turned but has not yet 
been turned on by the following predicate: 

requestl(i) = 3i : i < i A reql(i ) A (Vi : (i < i At < t) => ^turnonl(i )) 

Predicates request2(t) and requests (t) are specified similarly. Using this 
we can define a predicate specifying that the first request which has not been 
acknowledged is one. 

reqlfirst(i) = reql(i) A Vi : (i < i A request l(i ) A 

Vi : (i < i At < t) => ^requestl(i )) 

((req2(i ) 3i : t < t At < i A ^req2(i )) A 
(req3(i )=^3i : t < t At <t A ^req3(i ))) 

Again, predicates req2f irst (t) and reqSf irst (t) are specified similarly. With 
these basic predicates as building blocks we can give a specification closely related 
to the informal requirements of the example. 

Vi : (turnonl(i) V turnon2(i) V turnonS(i)) alloff(i) A 
Vi : turnon2(i) ^ (^reql(i) A req2first(i)) A 
Vi : turnonS(i) (^reql(i) A req3first(i)). 

An informal specification for the control of the crane containing three properties 
was given in Section 5.2. Each of these properties corresponds to one of the lines 
in the predicate above. For instance the first line of the predicate specifies that 
if a motor is turned on then all the motors are turned off. This corresponds to 
the first property that only one motor can be turned on at a time. Similar for 
the remaining two lines and properties. 

Since our basic control program specifies the order of the events in the indi- 
vidual tasks (first req, then turnon, and then turnoff), this specification will 
define the wanted behavior. 

From this specification Mona generates the minimal deterministic automaton 
which has 46 states and 276 transitions (six from each state). 

Should we want to change the control language of our example in such a way that 
all three tasks have equal priority, the overall structure of the control automaton 
would change. As the following example will show, modifying the logical formula 
is indeed quite comprehensible in the case of the LEGO® crane requirements. 
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Example 3. Say that we would like to change the requirements such that all 
motors are given equal priority, that is, they will be turned on in a first come 
first served manner. Using the logic-based specification, all we have to do is to 
change the last two lines of our specification slightly resulting in the following 
fifo requirement. 

Vt : (turnonl(t) V turnon2(f) V turnon3(t)) alloff(t) A 
Vt : turnonl(t) =4> reqlfirst(f) A 
Vt : turnon2(t) =» req2first(t) A 
Vt : turnon3(f) req3first(t). 

Note that the sub-formulae, such as, alloffO and req2first() are reused 
from the previous specification. As we can see it is relatively easy to change the 
specification using the previously defined primitives. 

From this specification Mona generates an automaton with 79 states and 474 
transitions. 

6 Merging Automata and RCX^'^ Code 

Given a control automaton and the basic control program, one can synthesize 
the complete control program. In this section we describe how to translate an 
automaton into RCX'''“ code and how this is merged with the existing RCX'''“ 
control program. For our example we have done this by hand. It should be clear 
from this section that only standard techniques are used and these can easily be 
carried out automatically. 

6.1 Wrapping the RCX™ Code 

The execution of the basic control program is restricted to sequences allowed by 
a control automaton as follows. Firstly, RCX'''“ code is generated for the control 
automaton and then this code is merged with the existing RCX''''^ code. Merging 
RCX^“ code with an automaton can in some sense be considered a program 
transformation. Each statement involving a request or writing to an output port 
is replaced by a block of code that tests whether the operation is legal according 
to the control automaton. For our example an action should be delayed if the 
control automaton does not allow it. Transforming the code for turning motor 0 
on, will lead to the following piece of code. 

While VAR, 4, 3, CONST, 1 ’While automaton has not accepted the command 
SetVar 31, CONST, 1 ’Arg := onO, the argument for the automaton 

GoSub 0 ’Run the automaton 

SetVar 4, VAR, 22 ’Local success := global success 

EndWhile 
On "0" 



’Execution of the actual commcuid 
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We have chosen to implement the automaton as a subroutine. Since arguments 
for subroutines are not allowed in the language, passing an argument to the 
automaton has to be done via a global variable. Similarly, since a subroutine 
cannot return a value, return values are also placed in global variables for the 
process to read. The while loop delays the action until the automaton accepts 
execution of it. 



6.2 Implementing Mutual Exclusion and Automata 

However, the idea described above is not sufficient since we will not allow more 
tasks to use the automaton simultaneously. In the RCX'''“ language the problem 
is obvious since we are using shared variables for passing arguments and results. 
In general, we also need exclusive access to the automaton since the outcome of 
the automaton depends on its state when execution begins. If a process accesses 
the automaton while it is used by another process, the state variable might be 
corrupted. Therefore we must have exclusive access to the automaton. 

In our implementation we have used Dijkstra’s algorithm to implement mu- 
tual exclusion between several processes [3]. But any correct mutual exclusion 
algorithm would of course do. The algorithm uses some shared variables but this 
is no problem in the RCX'''“ language since all variables are shared. There are 
no gotos in the RCX'''“ language. Therefore, we have used an extra while loop 
and a success variable for each task. Except from these details, the algorithm is 
followed directly. 

An automaton is implemented in the standard way by representing the tran- 
sition relation as nested conditionals of depth two branching on the current 
state and the input symbol respectively. The current state and the input sym- 
bol is represented by one variable each. This gives us a way to combine the 
run of an automaton with the execution of standard RCX'''“ code with wrapped 
input/output statements. 

6.3 Variations of the Method 

In the example an action is delayed if the control automaton does not grant 
permission at once. Depending on the problem to be solved the action taken 
when permission is not granted can vary. That is, there are various ways of 
handling this temporary lack of controller acknowledgment: 

— as in the above example where the task is busy wait asking the controller 
over and over whether its label had been enabled; but 

— one could also simply cancel or ignore the statement requesting permission 
and continue execution. This could be done by replacing the busy waiting 
while loop by an if statement. 

The former would often be the preferred approach in cases where the internal 
state of the code is important, such as, in our example, or in a train gate con- 
troller. The latter would be a good choice in cases where the code is written in 
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a reactive style, constantly changing output action based on newly read input, 
e.g. in autonomous robots. 

The property implemented by the automaton in the example was specific to 
the problem. One could also imagine using the method for general properties 
e.g. for protecting hardware against malicious sequences of actions. This leaves 
at least two options of where to put the automaton: 

— as in the example above where the automaton was put alongside the wrapped 
RCX'^ code. Placing the code implementing the automaton at this level 
seems a natural choice when dealing with properties about the behavior of 
a specific RCX^“ program solving a particular problem. 

— If the property is of a more general kind, one should rather place the au- 
tomaton at the level of the operating system. 

So far we have only considered untimed properties. One could easily imagine 
using automata with discrete time as control automata. This would open for a 
whole new range of properties to be specified, e.g. a minimum delay between 
two actions. In the example it would be possible to specify properties like that a 
minimum time of 5 seconds should pass between stopping the crane and starting 
to move the hook. 

On the RCX'''“ this could be realized by having a variable representing the 
discrete time. This variable could be updated by a task consisting of an infinite 
loop waiting for one time unit and then updating the variable. Assuming variable 
number zero represents the time, it could be updated by: 

SetVar 0, CONST, 0 ’Initialize the timer 

Loop CONST, 0 ’An infinite loop 

Wait CONST, 10 ’Wait for 1 sec. 

SumVar 0, CONST, 1 ’Update the timer 
EndLoop 

7 Conclusion 

We have used control automata in conjunction with basic control programs for 
synthesizing complete control programs. Using this method one can add to a 
basic control program a control automaton which will ensure certain safety prop- 
erties are satisfied. We have used M2L to specify the control automata and the 
Mona tool to translate formulae into automata. 

The approach has been implemented in the setting of the LEGO® RCX'''“ 
system. This has allowed for the possibility of testing the implementations on 
real physical systems. 

Based on our experiments we find the method well suited for synthesis of 
programs ensuring safety properties like the ones we have used. We find the 
main advantage of the method is the ease of testing different specifications. The 
separation of the active control program and the restricting automaton also 
allows for ensuring (new) safety specifications to existing control programs. In 




m 



critical systems one might consider the automaton only for monitoring actions, 
not restricting these, to avoid deadlocks. 

The main disadvantage of the method is the restriction to safety properties. 
Since the all concurrent tasks must access the automaton there is a danger of 
this becoming bottleneck. 

Future work There is an overhead connected with gaining exclusive access 
to the automaton and running it. How much time is spent on gaining access 
to the automaton of course depends on the arrival of input events. It would be 
interesting to calculate some specific times for this given some input sequences. 
A tool for translating RCX'^“ programs to timed models supported by Uppaal [8] 
exists [5] . Using Uppaal one can “measure” the time spent by a program from 
an input is read until the response arrives. 

The example presented in this paper only has one component (one crane) 
and the control restrictions are consequently imposed on that particular compo- 
nent only. One could easily imagine having several components in a distributed 
environment working to achieve a common goal. By use of modular synthesis 
and distributed control [12] via independence analysis [13] one can statically in- 
fer information about which constraints to put locally on the components and 
which to put on the (most often necessary) central controller. 
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fmod META is protecting META-LEVEL . 

sort TermSet . subsort Term < TermSet . 
var T : Term . var S : Substitution . var L : Qid . 
vars TL Before After : TermList . vars OP SORT : Qid . 
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